Adapt Perl commands to upcoming changes in MSYS2? Or drop Perl from Git for Windows?

[dscho]

As I documented in msys2/MSYS2-packages#5177 (comment), Perl will soon be reporting cygwin instead of msys when asking $^O for the operating system, and Git for Windows will have to adjust a couple of lines:

• in git cvsexportcommit: https://github.com/git-for-windows/git/blob/v2.47.1.windows.2/git-cvsexportcommit.perl#L40
• in git send-email: https://github.com/git-for-windows/git/blob/v2.47.1.windows.2/git-send-email.perl#L1486
• in git svn: https://github.com/git-for-windows/git/blob/v2.47.1.windows.2/git-svn.perl#L68

Git for Windows' installers already skip cvsexportcommit (among other remote helpers targeting the long-forgotten source code management tools CVS and Arch, remote helpers that upstream Git continues to carry probably only for the sole reason that it would take work to remove them, especially the tedious sort of work that is convincing the core Git developers on the Git mailing list, where even one single person using a feature might well prevent said feature from being deprecated as long as said user is a big name in the Linux world). Therefore my current thinking is that dropping cvsexportcommit (along with the rest of the CVS/Arch stuff) from Git for Windows is a better course of action than actually patching the code.

As for git svn: This might actually serve as a fine opportunity to drop (or at least deprecate) git svn support from Git for Windows. I suspect that it has been broken for a long time already, git-for-windows/MSYS2-packages#58 being my attempt to fix those breakages, and the fact that nobody has complained in almost 2.5 years since I opened that PR (and the fact that the breakage probably existed way longer than that and I only noticed when Subversion's regression tests failed in a local build) is highly indicative that continuing work on that Pull Request would be a lot of love's labor lost.

While we're already on the train of thought to deprecate parts of Git for Windows that require a lot of work for little gain, let's also have a long and hard look at Perl itself. The last two major version upgrades of Perl required me to spend quite a lot of time, and the most recent one failed somewhere, forcing me to postpone the upgrade, with Perl v5.40.1 swooping in before I could even take a look at the problems with v5.40.0.

Therefore, I could imagine that a bold (and potentially correct) move would be to also drop support for git send-email from Git for Windows, which would allow Git for Windows to stop shipping (and thus, building) Perl altogether:

$ git ls-files -- ':(exclude)Documentation/' ':(exclude)contrib/' ':(exclude)t/' \*.perl
git-archimport.perl
git-cvsexportcommit.perl
git-cvsimport.perl
git-cvsserver.perl
git-send-email.perl
git-svn.perl
gitweb/gitweb.perl

[PhilipOakley]

I could imagine that a bold (and potentially correct) move would be to also drop support for git send-email from Git for Windows, which would allow Git for Windows to stop shipping (and thus, building) Perl altogether:

I appreciate I haven't contributed for a while, but I did (and hopefully will) use git send-email (and git format-patch) to contribute to the Git List. What other convenience methods would be recommended if Perl was dropped?

I can see the maintenance benefit of dropping all that other clutter but, as noted, ..

upstream Git continues to carry probably only for the sole reason that it would take work to remove them, especially the tedious sort of work that is convincing the core Git developers on the Git mailing list, where even one single person using a feature might well prevent said feature from being deprecated..

git send-email being that usage for me 😃 .

[dscho]

I did (and hopefully will) use git send-email

Is there a Perl version you can easily download? You'd likely have to put in some effort to make Git.pm/git-send-email.perl truly cross-platform, as there are most likely "All The World Looks Like Unix" assumptions baked in all over the place, if I know Git's source code well.

Or maybe you can switch to using regular MSYS2 (I do hope that we're already in a place that is relatively close to MSYS2 being able to consume mingw-w64-git updates from Git for Windows, and if you promise not to bother me with any problems but resolve them yourself, I even encourage you to download and install the Pacman packages from the git-artifacts run's pkg-x86_64 artifacts).

What other convenience methods would be recommended if Perl was dropped?

GitGitGadget. Although I have to admit that that project probably needs more engagement from the community, especially development-wise, if it is to be viable for the long term.

even one single person using a feature might well prevent said feature from being deprecated..

git send-email being that usage for me 😃 .

I hate to be the one to tell you @PhilipOakley, but you're not a big name in the Linux world, and therefore they wouldn't keep the tool around just for you.

As it were, though, git send-email is used heavily by the core Git developers (kind of required, really, due to their choice of running a project without proper project management tools and instead doing everything on a mailing list, including code patch review). So there is no need to fear git send-email losing support in the Git project.

As for Git for Windows, that's a different story. I am totally willing to abandon support for that if that is the only tool requiring a full Perl and then some modules.