git: use mingw-w64-perl

[MehdiChinoune]

perl packages are not available for mingw64.

I'll mark it as a draft until git-for-windows move to UCRT64 git-for-windows/git-sdk-64#117

[dragon-archer]

Not sure whether asciidoctor is a hard dependency of git, if not, maybe we can disable it for mingw32 like rust, and then we can drop ruby from mingw32.

[MehdiChinoune]

Not sure whether asciidoctor is a hard dependency of git, if not, maybe we can disable it for mingw32 like rust, and then we can drop ruby from mingw32.

asciidoctor is required documentation. I don't know how to disable that.
If you look at my changes, I dropped mingw32.

[dragon-archer]

If you look at my changes, I dropped mingw32.

Fine, happy with the mingw32 drop, though I'm not sure whether we should keep mingw64 for some time.

[ognevny]

cc @dscho

[MehdiChinoune]

Fine, happy with the mingw32 drop, though I'm not sure whether we should keep mingw64 for some time.

What do you mean, As I metioned above perl packages are not available for mingw64 since no new packages for it.

[dragon-archer]

What do you mean, As I metioned above perl packages are not available for mingw64 since no new packages for it.

perl is only used by some subpackages, not git itself, so maybe we can skip these subpackages? (Just a rough idea of myself, I think we should let @dscho to decide.)

[dscho]

asciidoctor is required documentation. I don't know how to disable that.

We could optionally use asciidoc for mingw32 instead, if that helps?

perl packages are not available for mingw64.

You really scared me, saying that perl is no (longer?) available for mingw64. Having been scared into reviewing thoroughly what your patch does, between all that extensive white-space change (which I am really opposed to, as it makes my life as Git for Windows maintainer unnecessarily hard, and actively undoes a lot of the sync work I put into making sure that MSYS2's and Git for Windows' copy of mingw-w64-git/ are identical), I now understand what you're trying to do: You wanted to say that the mingw-w64-perl package is not available for mingw64, not the perl package.

What do you mean, As I metioned above perl packages are not available for mingw64 since no new packages for it.

perl is only used by some subpackages, not git itself, so maybe we can skip these subpackages? (Just a rough idea of myself, I think we should let @dscho to decide.)

Currently, mingw-w64-git-perl depends on perl (and not on mingw-w64-perl):

package_git-perl () {
  depends=("${MINGW_PACKAGE_PREFIX}-${_realname}=${pkgver}"
           "perl>=5.14.0"
           "perl-Error"
           "perl-libwww"
           "perl-TermReadKey")
  pkgdesc="Perl module for Git (mingw-w64)"


  cd "$srcdir"/git


  # Install Git.pm and related Perl modules (excluding Git::SVN)
  make -j1 -f ../mingw-w64-git.mak DESTDIR="$pkgdir" install-perl-module
}

It is an easy change to make to replace that by the mingw-w64-perl variant.

However, that is the easy part. The hard part, and the actual blocker for this here PR, is proving that that works. You see,

There are deep-seated assumptions in Git.pm about the ecosystem within which it runs, e.g.

• the directory separator is '/`'
• /dev/null is a thing
• line endings consist of a single Line Feed, not of Carriage Return and Line Feed
• path lists are separated with : (which is incompatible with Windows-style paths starting with <drive-letter>:\)

So I would be utterly surprised if any Git command that uses Git.pm would work with mingw-w64-perl at all. Most likely any such command will fail immediately.

[dscho]

all that extensive white-space change (which I am really opposed to, as it makes my life as Git for Windows maintainer unnecessarily hard, and actively undoes a lot of the sync work I put into making sure that MSYS2's and Git for Windows' copy of mingw-w64-git/ are identical)

To clarify:

I wish that a mere few lines' change wasn't blown up into a +110/-123 diff.

[MehdiChinoune]

@dscho I said perl packages, not perl itself.
I replaced tabs with whitespaces because that what we use in this repo.
I kept the PR a draft because I want to make sure that git-perl works with mingw-w64-perl before merging it.

[dscho]

I replaced tabs with whitespaces because that what we use in this repo.

Okay, if you insist. But why is this not a separate, clean and elegant commit?

[dscho]

I kept the PR a draft because I want to make sure that git-perl works with mingw-w64-perl before merging it.

I would really appreciate it if this was done in a collaborative manner, more collaborative with the Git for Windows project, that is. I could have told you before you even started that this is not as simple as opening a PR in this here repository. You will need to put in substantial work in the git-for-windows/git repository itself. I can help you get started this, e.g. by pointing you to https://gitforwindows.org/building-git, https://gitforwindows.org/running-gits-regression-tests.html#running-individual-tests and mentioning that the most important Perl tests are t9700-perl-git, t9001-send-email and t91*-svn*.

When I upgraded Perl and fixed Subversion in MSYS2, I also ran all the git-svn tests to make sure that everything works, which combined took many dozens of hours of my time and several thousands of dollars worth of AI tokens. You will now understand why I react as I do when I see that all of this work and money might come to be made into Sunk Cost through a single PR.

And even if all of that worked, you would force me to adapt all the process tooling in Git for Windows to use mingw-w64-perl instead of perl, not a light undertaking.

When I opened #16383 and put hundreds of hours of work into addressing it, I meant to collaborate with the MSYS2 project, not to have one-sided decisions. I am happy to align with MSYS2's white-space rules (even though I am fairly certain that the current shape is based on a very ancient form of MSYS2's package definitions and therefore those rules must have changed under me in the meantime). I am not so happy to see the friction caused by this here PR. So I seriously hope to see a turn-around here. In hindsight, it would most likely have been a much wiser idea to start this out as a Discussion instead of a Pull Request.

My first question would have been: why? Actually, I would have adapted Schneier's five-step process:

1. What problem does it solve?
2. How well does it solve the problem?
3. What new problems does it add?
4. What are the economic and social costs?
5. Given the above, is it worth the costs?

If the problem it tries to solve is to make mingw-w64-git* not rely on MSYS packages, the endeavor is doomed from the get-go: Git's incredibly strong reliance on a working Unix shell for all things from launching git-upload-pack for every git fetch to running hooks, the editor, the pager (which is less by default and hence also an MSYS package) makes that a no-go. One Does Not Simply Remove Git's Dependency On MSYS Packages.

If you still choose to go forward with making Git work with mingw-w64-perl (which, given the above's promise of requiring several dozens of hours of intense work, I wouldn't fault you if you gave up, like others before you, see here, here and here), you have to keep in mind that git svn is not the only Git command relying on Perl, not even the most important one: that would be send-email. You will really have to make sure that that works, even if Git's test suite's code coverage is historically known to be distributed incredibly unevenly (and therefore quite a few crucial code paths in send-email/git svn might very well be missed, no matter how over-exercised some other code paths are).