Re: [ANNOUNCE] GIT 0.99.9g

[Andreas Ericsson <ae@op5.se>]

H. Peter Anvin wrote:
> Jeff Garzik wrote:
> 
>>
>>> Oh, and we will not be moving things out of /usr/bin/ during 1.0
>>> timeframe.
>>
>>
>>
>> :(  bummer.  I do like the elegance of having /usr/bin/git executing 
>> stuff out of /usr/libexec/git.
>>
>> /usr/libexec/git also makes it IMO cleaner when integrating git 
>> plugins from third parties (rpm -Uvh git-newfeature), because you 
>> don't have to worry about the /usr/bin namespace.
>>
> 
> It's nice in concept, but I think there are a lot of reasons why this is 
> a bad idea:
> 
> - "man" doesn't handle it.  It would be another thing if "man" could be 
> taught to understand commands like "man cvs checkout" or "man git fetch".
> 

This is moot. man-pages can still be named git-fetch.

> - There is no general way to teach shells etc about it, for tab 
> completion etc.
> 

Add the lib directory to the path (for git-<tab><tab>) or have it 
auto-evaluate the result of a git command-listing.

> - Makes it harder (but not impossible) to run git from a build directory 
> without installing it first.
> 

Provided adding --lib=. is considered difficult, yes. Btw, this problem 
still applies as some of the programs run other programs that are 
expected to be in the path.

I've just posted a patch (used my submit-patch script, which was stupid 
since I should have posted it here) that doesn't have any of these problems.

> In comparison, the issue of clutter in /usr/bin is actually a pretty 
> small issue, especially with htree.  Most vendors have gone back to 
> putting everything into /usr/bin since all variants that involve 
> splitting it up seem to be more of a loss than a gain.
> 

Fair enough. With the patch I've just sent (C implementation of the 
'git' program) this option is certainly available.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231