Re: git binary directory?

Linus Torvalds [off-list ref] writes:

Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever 
try to use the horrid gnome executable finder on it when you want to 
convince firefox to use xpdf instead of that broken crap called "evince"? 
Takes absolutely ages and is horrible).

And git made it about 4% worse all on its own.

My pragmatic half agrees with what you said.  /usr/bin should
not contain things that are never used by the end user -- things
like git-sh-setup, git-fmt-merge-msg, and git-merge-recursive
should not be there.  Not having things like git-show-branch and
git-update-index in /usr/bin is a regression because it needs an
extra fork to call them through 'git' wrapper, but I could live
with that.

My purist half, however, says that it is a wrong solution to the
problem.  If having many files in /usr/bin hurts performance,
you should be using a filesystem that handles large directory
better.  Modern shells already know how to hash command names
found in $PATH.  It is just your gnome executable finder that is
lacking the knowledge of which binaries are appropriate for what
mimetype; perhaps your distribution could help by having a way
for each package to register programs that handle particular
mimetypes well with the system-wide database.

And my lazy remainder (yes, I add up to more then one ;-))
cheers on my purist side.

But common sense prevails at the end of the day.  I would not
fight a battle I know I would not be able to win.  So what
should we do about this problem?  And when?

Since we do not have enough clout to have /usr/bin/git/ and ask
the users to put that in their PATH like X11 does, we need to
teach some of our commands that use other git commands to
prepend /usr/lib/git/ (or /usr/libexec/git) on their PATH while
they run.  Although many of the Porcelainish commands include
git-sh-setup, git-sh-setup itself is a prime candidate to be
kicked out of /usr/bin, which means essentially everything needs
to have that PATH trick.

This also is a bit inconvenient for our in-source-tree tests.
We need to be testing what we just built and are about to
install, not what is already installed, so every script needs to
start with something like this:

	#!/bin/sh
	: ${GIT_BIN_DIR=@@GIT_BIN_DIR@@}
        PATH="$GIT_BIN_DIR:$PATH"
        git-sh-setup || die "not a git repository"
	...

and our test will run with GIT_BIN_DIR set to `pwd`/../../ (they
run in t/trash and what we just built are found at the toplevel
of the source).  Also we need to do the same for binaries if they
fork/exec other git commands.

Commands like upload-pack and receive-pack are directly executed
from the ssh connection, and we need to arrange for them to be
found on the PATH of users' non-login shells.  This does not
necessarily mean these commands need to stay in /usr/bin, but if
we move them outside standard PATH, we would need to teach
.bash_profile vs .bashrc workaround to all users, which I think
is the yuckiest part of all of the above.