Subject: Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

From: Andreas Ericsson <[email-masked]>
Date: Wed, 27 Aug 2008 10:32:51 +0200

H. Peter Anvin wrote:
> Jean Delvare wrote:
>>
>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but
>> to the silent majority I am a proud member of, it was. (I'm not saying
>> that the path that was taken to get there was optimal, just that the
>> goal was sound.)
>>
> 
> You keep trying to use the Nixon argument ("silent majority.")  You *do* 
> know that it was a rhetorical device used by Nixon's speechwriters to 
> push ahead with policies despite compact opposition, don't you?
> 
> As far as I can tell, most of the arguments in favour came from fanbois 
> of $OTHER_SCM which went along the lines of "why does git need all this 
> stuff in /usr/bin, when $OTHER_SCM doesn't?"  It had nothing to do with 
> reality, of course; it was just a difference between git and $OTHER_SCM 
> which they choose to pick on.
> 

Well, some new users both here and on #git have been slightly bewildered
about the number of commands the default bash-completion show when typing
git<tab><tab>. If anything, the move is long overdue, or should have
waited until 2.0 where people would expect to have to re-learn quite a lot.

There were, initially, two drawbacks with having the git-<commands> outside
the users $PATH. The first was performance when used from scripts, which
was addressed in November 2005 when the git wrapper was rewritten in C,
prior to the 1.0 release.
The second is the shell-completion, which was added in September 2006,
prior to the 1.5 release.

In retrospect, it would probably have been a good thing to make the move
with the 1.0 release (which would likely have caused the bash and zsh
completion scripts to pop into existence a lot earlier than 1.4.2), or
in 1.5, when both reasons for keeping the commands in the path were simply
not there anymore. 1.5 was also informally nicknamed "the UI release", so
it would have sort of fitted in there, while 1.0 was the first "this is
how git will work for the foreseeable future" release, so anything before
1.0 could be considered beta software with a very flexible and fast-moving
UI.

Worth remembering for the future perhaps, although I know it's easy to
overlook the fact that the inertia of the userbase grows exponentially
with the headcount of the same.

-- 
Andreas Ericsson                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231