Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 22, 2007, 10:47 UTC
Message-ID: <Pine.LNX.4.64.0706221140140.4059@racer.site>
In-Reply-To: <20070622013026.GY14298@menevado.ms.com>

Hi,

On Thu, 21 Jun 2007, Kevin Green wrote:

Show 19 quoted lines

> On 06/18/07 20:16:47, Johannes Schindelin wrote:
> > Hi,
> > 
> > On Fri, 15 Jun 2007, Kevin Green wrote:
> > 
> > > I'm thinking I like the env var idea much more though.  I can just 
> > > export it in my shell and it works in both cases.
> > 
> > And it completely breaks down when you have more than one remotes. Or when 
> > you cd to another project with another remote. Or etc. IOW it is fragile.
> > 
> > Clearly, the config approach is the only one which makes sense. This 
> > information is so closely coupled to a specific remote that you should 
> > store it right where you store all the other remote information, too.
> > 
> 
> You're absolutely right.  I agree, except that in _my_ environment git 
> will be in a non-standard path but *always* consistently in the same 
> place.  I'm being greedy here. :)

Note that this "solution" will _only_ work for you.

> The config approach is clearly the most versatile.  The question I have 
> is, is there a good reason not to provide the third option of setting 
> env var?  I suppose that in the more likely case this could cause more 
> harm than good, i.e. maybe this is too specific for my use case.

Since it will _only_ work for you, I think there is more harm done than good, by including that in mainline git. Just think of somebody seeing this mentioned in the docs, not reading further properly, and just getting confused, blaming it on Git.

Instead, we have that wonderful config solution, which is the proper one anyway, and which does not confuse people, once they found it.

However, Git is all about the freedom to fork and merge. So do the same as me: keep those changes in your local repo, and do not use mainline Git.

For example, I have this option "-t" to Git, which automatically tries to give human-readable names to all the 40-character object names, and does not change colouring. Thus, I can say

	git -t log -p whatever.c

to find exactly which commit introduced a certain feature (which I find by searching the diffs). Then, I only have to copy&paste the nice commit name into the mail/IRC where I am responding to, and be done.

This feature was not liked on the list, so it remains in my local fork forever (though it is also stored in the mail archives).

Ciao, Dscho