On Tue, Apr 01, 2025 at 08:26:36PM +0200, Johannes Schindelin wrote: > On Thu, 27 Mar 2025, Patrick Steinhardt wrote: > > > In the early days of Git, Perl was used quite prominently throughout the > > project. This has changed significantly as almost all of the executables > > we ship nowadays have eventually been rewritten in C. Only a handful of > > subsystems remain that require Perl: > > > > - gitweb, a read-only web interface. > > > > - A couple of scripts that allow importing repositories from GNU Arch, > > CVS and Subversion. > > > > - git-send-email(1), which can be used to send mails. > > There is also `git request-pull` which is a _shell_ script that runs > `perl` to parse the output of `ls-remote`, and there is `git > filter-branch` (which was apparently not yet dropped?) that uses Perl if > the `--state-branch` option is in use. Ah, indeed, thanks! I should probably mark both of these to require Perl in our build systems so that we have a source of truth what requires Perl and what doesn't. git-filter-branch(1) also looks somewhat broken because it uses Perl directly instead of using PERL_PATH. On the other hand, maybe the better fix would be to just convert tools to not use Perl at all anymore so that we can eventually get rid of this dependency altogether. It feels like we're quite close, and many of these conversions are low-hanging fruit. > The patch looks good, in particular when fetching the `b4/pks-t-perlless` > branch from https://gitlab.com/gitlab-org/git and inspecting 8fc639f99d9f > manually, as it is a rather large patch that is pretty much unreviewable > on a mailing list. > > Using several write-only `sed` invocations, I identified that there are > only three hunks that are neither adding a stand-alone `PERL_TEST_HELPERS` > prereq nor adding a test preamble of this form: > > if ! test_have_prereq PERL_TEST_HELPERS > then > skip_all='skipping <something>; Perl not available' > test_done > fi Thanks for double checking! Patrick
