Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From
Andreas Ericsson <ae@op5.se>
- Date
- Aug 27, 2008, 08:32 UTC
- Message-ID
- <48B51133.1030400@op5.se>
- In-Reply-To
- <48B46443.6000800@kernel.org>
H. Peter Anvin wrote:
Show 18 quoted lines
> 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 andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231