Jeff King wrote (2008-08-26 13:07 -0400): > On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote: > > > > git-<tab><tab> ... what? 140-something commands? I'll better start > > > looking for alternatives _right now_! > > > > Actually, this is the only realistic argument I can remember at all. > > Are there any others? I couldn't come up with any - but I didn't do > > much history digging: others seem to be equally in dark, though. > > The three reasons I can recall are: Don't know about "original" reasons but filling users' ~/bin isn't nice either. I always install all of the self-built git under $HOME. Since "make install" (by default) used to fill ~/bin with those 140 git-* executables I already configured git to install itself to a custom directory. I had to use $GIT_EXEC_PATH and create some symlinks but with 1.6.0 I don't have to do this anymore. Me happy. Setting $GIT_EXEC_PATH wasn't a big deal and I can't see it being a big deal now, for some other people, to extend their $PATH to include every imaginable git-* executable in the system. BTW I'd also vote for reducing the number of commands printed with "git <tab><tab>" bash-completion. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html