Humble request of 'git' developers

Humble request of 'git' developers

[Jeff Garzik]

Please stop filling up my /usr/local/bin :)

Just have one 'git' script, which looks in /usr/local/libexec/git for 
further scripts and backends programs like write-tree and diff-cache.

Also, please don't assume that "." is in PATH.  I think there is at 
least one invocation of commit-id with that assumption, in git-pasky-0.6.3.

	Jeff

Re: Humble request of 'git' developers

[Chris Wedgwood]

On Sat, Apr 23, 2005 at 03:58:26PM -0400, Jeff Garzik wrote:

> Please stop filling up my /usr/local/bin :)

why?

> Just have one 'git' script, which looks in /usr/local/libexec/git
> for further scripts and backends programs like write-tree and
> diff-cache.

how is that really any better?

> Also, please don't assume that "." is in PATH.  I think there is at
> least one invocation of commit-id with that assumption, in
> git-pasky-0.6.3.

That I'll buy.  I don't know of anyone who places "." in PATH.

Re: Humble request of 'git' developers

[Jeff Garzik]

Chris Wedgwood wrote:
> On Sat, Apr 23, 2005 at 03:58:26PM -0400, Jeff Garzik wrote:
> 
> 
>>Please stop filling up my /usr/local/bin :)
> 
> 
> why?
> 
> 
>>Just have one 'git' script, which looks in /usr/local/libexec/git
>>for further scripts and backends programs like write-tree and
>>diff-cache.
> 
> 
> how is that really any better?

Because

* flat namespaces grow cumbersome

* if everybody uses the 'git' command, which does all the internal 
execution, then it's just namespace pollution.

* using a multi-level namespace allows you to create commands like "rm" 
and "mv" by simply dropping that stuff into /usr/libexec/git, without 
having to worry about conflicting with rm(1) and mv(1).

	Jeff

Re: Humble request of 'git' developers

[Chris Wedgwood]

On Sat, Apr 23, 2005 at 04:09:09PM -0400, Jeff Garzik wrote:

> * flat namespaces grow cumbersome

agreed

> * if everybody uses the 'git' command, which does all the internal
> execution, then it's just namespace pollution.

sure, but not everyone body is

i agree everybody *should* and then it can go into <prefix>/libexec or
similar

Re: Humble request of 'git' developers

[Sanjoy Mahajan]

[Added David Wheeler to the CC given his (admirable) pushes for wide
standards compliance.]

>>>Just have one 'git' script, which looks in /usr/local/libexec/git
> [or] /usr/libexec/git

The FHS <http://www.pathname.com/fhs/pub/fhs-2.3.html> looks like it
recommends a /usr/lib/git directory:

  /usr/lib : Libraries for programming and packages

  Purpose
     /usr/lib includes object files, libraries, and internal binaries that
     are not intended to be executed directly by users or shell scripts.

     Applications may use a single subdirectory under /usr/lib. If an
     application uses a subdirectory, all architecture-dependent data
     exclusively used by the application must be placed within that  
     subdirectory.

My Debian sarge system has one libexec-like directory, but it follows
the FHS:

$ locate '/usr*libexec*'
/usr/lib/php4/libexec

-Sanjoy

Re: Humble request of 'git' developers

[Petr Baudis]

Dear diary, on Sat, Apr 23, 2005 at 09:58:26PM CEST, I got a letter
where Jeff Garzik <jgarzik@pobox.com> told me that...
> Please stop filling up my /usr/local/bin :)
> 
> Just have one 'git' script, which looks in /usr/local/libexec/git for 
> further scripts and backends programs like write-tree and diff-cache.

Ad core git, yes, one of the reasons why I decided for the Cogito rename
was to free the "git namesace" for the git programs. :-)

> Also, please don't assume that "." is in PATH.  I think there is at 
> least one invocation of commit-id with that assumption, in git-pasky-0.6.3.

Yes, sorry, fixed and pushed out.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor