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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Pat,

On Thu, 12 Jan 2017, Pat Pannuto wrote:

> 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