Skip to contentSkip to conversation

Humble request of 'git' developers

DISCUSSION Jeff Garzik 4 participants 6 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 1 line · Jeff Garzik

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

why?

Quoted 3 lines

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?

Quoted 3 lines

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.

#2 lore raw
Quoted 9 lines · Chris Wedgwood
Quoted 1 line · Jeff Garzik

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

why?

Quoted 6 lines
Quoted 3 lines

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

#3 lore raw
Quoted 1 line · Jeff Garzik

* flat namespaces grow cumbersome

agreed

Quoted 2 lines

* 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

#4 lore raw
In reply to Jeff Garzik

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

Quoted 2 lines
Quoted 1 line
Quoted 1 line

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

#5 lore raw
In reply to Jeff Garzik

Dear diary, on Sat, Apr 23, 2005 at 09:58:26PM CEST, I got a letter where Jeff Garzik <[email protected]> told me that...

Quoted 4 lines

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. :-)

Quoted 2 lines

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.

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