Jeff King <peff@peff.net> writes:To me, one of the two saddest part of this story is this. I was among the "don't change anything, get used to it just like old timers are already used to" camp, when people said that having many commands in /usr/bin (or $HOME/bin) would scare people and pushed for this change, around the end of 2005 through early 2006. The pros-and-cons wasn't clearly cut-and-dried. Moving out of /usr/bin has slight technical merits (e.g. "bash completion not showing 150+ commands but only selected Porcelains", "not scaring people off", "dashless form is needed if you want to use global options", and "moving away from dashed form will eventually let us get rid of copies on systems without hardlinks even from under /usr/libexec/git-core"). But I do not think the advantage was so great. When I hear something like what David Woodhouse said in this thread, I should be feeling "People -- those of you who claimed to be the silent majority -- see, I told you so! This is a very bad move". But I can't. People who complain _now_ just annoy me even more. Why weren't you defending the backward compatibility with me, which you seem to value it so much, perhaps even more than I did back then? Why are you wasting our time bringing it up again, instead of joining the discussion when it _mattered_ back then? And I still think there is no great reason to pick one way or the other. Having everything in /usr/bin does not have any better reason than "it has been that way from the beginning", and that certainly is not a reason strong enough to revert this anymore, as the opposition now has "the latest and greatest was shipped with the new layout" which is an equally valid argument. Another, even more sad part of this story is that the thread was confused into talking about the change that has already happened, which is a total offtopic, and wasted even more time from people. Read the subject line again, and notice that we are not talking about /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about removing "git-add" and friends from /usr/libexec/git-core/, so that we do not have to even have these many hardlinks there. Except for Linus (and obviously myself who started the thread), I saw nobody expressed any opinion on it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Alex Samad | page swap allocation error/failure in 2.6.25 |
| Bart Van Assche | Re: Integration of SCST in the mainstream Linux kernel |
| Andrea Arcangeli | [PATCH 06 of 11] rwsem contended |
| Chuck Ebbert | Why do so many machines need "noapic"? |
git: | |
| Andy Parkins | svn:externals using git submodules |
| Elijah Newren | Trying to use git-filter-branch to compress history by removing large, obsolete bi... |
| Marcus Griep | [PATCH] git-svn: Make it scream by minimizing temp files |
| Tommi Virtanen | [PATCH] "git shell" won't work, need "git-shell" |
| Marcos Laufer | dmesg IBM x3650 OpenBSD 4.3 |
| Theo de Raadt | Re: Chatting with developers? Is it soo 1996? |
| Ted Unangst | Re: MAXDSIZ 1GB memory limit for process |
| Richard Stallman | Real men don't attack straw men |
| Denys Fedoryshchenko | Re: thousands of classes, e1000 TX unit hang |
| Suresh Siddha | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
| Simon Horman | Re: [PATCH] sendfile() and UDP socket |
| Jeff Garzik | Re: [PATCH] sky2: jumbo frame regression fix |
