Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 12, 2017, 10:21 UTC
Message-ID: <alpine.DEB.2.20.1701121118170.3469@virtualbox>
In-Reply-To: <CAAnLKaGbf9-GAF19+61=7_RfCOBM0=Ounwf8KkL1jS6HX3pOag@mail.gmail.com>

Hi Pat,

On Thu, 12 Jan 2017, Pat Pannuto wrote:

Show 16 quoted lines

> I'm not at all attached to changing all of them, just figured it made
> sense while I was here.
> 
> Would a patch that changes only:
> 
>  git-add--interactive.perl                     | 2 +-
>  git-archimport.perl                           | 2 +-
>  git-cvsexportcommit.perl                      | 2 +-
>  git-cvsimport.perl                            | 2 +-
>  git-cvsserver.perl                            | 2 +-
>  git-difftool.perl                             | 2 +-
>  git-relink.perl                               | 2 +-
>  git-send-email.perl                           | 2 +-
>  git-svn.perl                                  | 2 +-
> 
> be more acceptable?

Unfortunately not. Take git-svn.perl for example, in particular in conjunction with Git for Windows. git-svn requires the Subversion bindings for Perl, and they are a *major* pain to build correctly (this is frequently underestimated by users who complain about git-svn problems).

Allowing users to override the Perl path (even if it were possible, which it is not, as Hannes Sixt pointed out in the mail you replied to) would open Git for Windows for a metric ton of users complaining that their git-svn does not work (when it is their fault, really, by overriding Perl with their own preferred version that comes without Subversion bindings, but how would they know).

So if this patch would make it into upstream Git, I would *have* to revert it in Git for Windows, adding to my already considerable maintenance burden.

Ciao, Johannes