Re: git binary directory?

From: Junio C Hamano <junkio@cox.net>
Date: Nov 6, 2005, 05:37 UTC
Message-ID: <7vy84249re.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511052013550.3316@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 8 quoted lines

> We have directories for a reason. You might as well argue that everybody 
> should have a flat namespace, since it should be efficient.
>
> The performance reason for directories is only secondary. The _real_ 
> reason for directories is to keep related things together, and track them 
> better. Havign a nice directory structure where programs keep their own 
> files instead of putting them all in the same place is a good thing from 
> an organization standpoint.

My point (actually, my purist half's point) is that /usr/bin is that nice structure that keeps related things together --- the relatedness of them being "the end user would want to run them". Your initial hesitation that the change being discussed would force you to say "git whatchanged" when you are so accustomed to type git-whatchanged is valid. Unfortunately, we have far more commands in /usr/bin than good old V7 days, and while the _primary_ purpose of /usr/bin is to hold "the end user would want to run them" things together (hence, shell needs to know only about handful places to look at), having thousands of things in one place is inconvenient for purposes other than the primary purpose of that grouping (i.e. running them), such as browsing them.

You could deviate from the UNIX tradition and "keep related things together" in different ways; you _could_ have /usr/bin/pdf-viewers/, /usr/bin/html-viewers/, etc. to hold xpdf, acroread, firefox and iexplorer in them if you do not like /usr/bin/ that has many executables -- but we do not do that.

> (In fact, that PATH part of the patch is probably a bug-fix regardless: if 
> I have two different versions of "git", and I ask for the one that isn't 
> in my path explicitly, then it should use _its_ git programs, not the 
> other versions).

I think that is a valid change.

> The gnome file chooser is horrid, but even in the presense of a _nice_ 
> file manager it's actually not very pleasant to have directories with 
> thousands of files.

Yes, but I think we should blame UNIX tradition for that ;-).

> Did you miss that part of my patch?

Sorry, my reply was prepared before I actually saw that patch (you would notice it was a reply to your first message). I think what you did in your patch makes sense. The end users should always say 'git update-index' (or know the lib/git path and it they want to say git-update-index), even when running the low-level commands, and as long as they use 'git' wrapper that approach would work.

> Yes. All porcelain would need to do the PATH thing, I think.

No, we could just say 'git commit' and 'git' is the only thing that needs to know the PATH thing, as you did.

> But yes, you're right that right now we're not always set up for this, and 
> git-upload-pack etc that execute directly from the shell would need help.

We _could_ even invoke 'git upload-pack' from 'git-fetch'.