more 'git' cleanups

[ognevny]

No description provided.

[ognevny]

I'm trying to track every package that actually uses git during the build, but it seems that some are built without logging its usage (and pre-installed GfW is used). let me know if there are such

[oscarfv]

With this, if you locally build a package in multiple environments (as is often the case while maintaining PKGBUILDs), git is installed for each environment, while before you had only one git install.

For the purposes of building packages, does GfW provide any advantage over MSYS2 git?

[ognevny]

With this, if you locally build a package in multiple environments (as is often the case while maintaining PKGBUILDs), git is installed for each environment, while before you had only one git install.

the same applies... to all MINGW package

For the purposes of building packages, does GfW provide any advantage over MSYS2 git?

theoretically should be faster

[oscarfv]

With this, if you locally build a package in multiple environments (as is often the case while maintaining PKGBUILDs), git is installed for each environment, while before you had only one git install.

the same applies... to all MINGW package

Not really. Although you could set up a cross-compiling toolchain in MSYS, it would be complex and inconvenient for users, so we distribute a complete toolchain per environment. Other makedepends (such as CMake) want to be used from the same environment they work for.

For the purposes of building packages, does GfW provide any advantage over MSYS2 git?

theoretically should be faster

The most time-consuming work git does for building PKGBUILDs is cloning. I don't think that will run significantly faster.

git is a fat dependency, and installing it multiple times must be backed by showing a good enough improvement in a metric important for us.

[lazka]

(and pre-installed GfW is used)

in theory it shouldn't be, it isn't in PATH during building.

For the purposes of building packages, does GfW provide any advantage over MSYS2 git?

it outputs Windows paths.

[ognevny]

(and pre-installed GfW is used)

in theory it shouldn't be, it isn't in PATH during building.

at least CMake use it. probably go uses it too

[oscarfv]

For the purposes of building packages, does GfW provide any advantage over MSYS2 git?

it outputs Windows paths.

Since building packages is driven by MSYS2 and paths are translated back and forth all the time, is this an advantage in practice? Do we know of any package that benefits from this?

[lazka]

Since building packages is driven by MSYS2 and paths are translated back and forth all the time, is this an advantage in practice? Do we know of any package that benefits from this?

We don't translate stdout. We patched all git users to use relative paths (various python packages, like poetry, setuptools-scm, gitk).

But I don't see the issue, we try to keep mingw and msys separate where we can and I don't see why git would be different. Disk space shouldn't be an issue for package development.

[oscarfv]

Since building packages is driven by MSYS2 and paths are translated back and forth all the time, is this an advantage in practice? Do we know of any package that benefits from this?

We don't translate stdout. We patched all git users to use relative paths (various python packages, like poetry, setuptools-scm, gitk).

In setuptools-scm/PKGBUILD and poetry/PKGBUILD I don't see anything git-related. Actually, they don't have git on their makedepends, so I don't understand this.

But I don't see the issue, we try to keep mingw and msys separate where we can and I don't see why git would be different. Disk space shouldn't be an issue for package development.

Well, it is for me. I work on virtual machines and anything that adds disk usage is an inconvenience when those are copied, moved or an snapshot is taken/restored. On both host disk usage and time required for each operation.

Add to that the increased download time. It is not uncommon here to get download speeds of a few dozens KB/s while updating packages.

All of the above are not insurmountable issues and I'm very happy about having GfW on our repos, but this PR has not zero negative impact either.

[lazka]

In setuptools-scm/PKGBUILD and poetry/PKGBUILD I don't see anything git-related. Actually, they don't have git on their makedepends, so I don't understand this.

pypa/setuptools-scm#520 python-poetry/poetry-core#704 Not saying that it is a huge issue, just something that has to be handled by some things calling git.

[oscarfv]

pypa/setuptools-scm#520 python-poetry/poetry-core#704 Not saying that it is a huge issue, just something that has to be handled by some things calling git.

Thanks. Those specific cases need to be fixed for Cygwin anyway.

In the general case, if some MINGW-package depends on git at run time, make it depend on GfW is the right thing, probably.

[lazka]

Some numbers:

CLANG64:

385MB base-devel
1.22GB with clang added
1.39GB with cmake added
1.47GB with git added

UCRT64:

385MB with base-devel
945MB with gcc added
1.09GB with cmake added
1.16GB with git added

(cmake pulls in various deps also needed by git, but that's also very common, so I added it)

imo, so while it might make things worse for your use case if , it's really not much compared to everything else you need to build stuff. also cygwin git pulls in lots of deps, so it might take two mingw git instances for it to make a difference.

Thanks. Those specific cases need to be fixed for Cygwin anyway.

They are MSYS2 specific, no one mixes native python with cygwin git besides us. Cygwin uses cygwin python, everyone else uses git4win.