Thread (7 messages) 7 messages, 4 authors, 2016-06-15

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:17

Hi,

On Thu, 21 Jun 2007, Kevin Green wrote:
On 06/18/07 20:16:47, Johannes Schindelin wrote:
quoted
Hi,

On Fri, 15 Jun 2007, Kevin Green wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help