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
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| H. Peter Anvin | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Christoph Lameter | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
git: | |
| Christoph Hellwig | Re: [PATCH 06/32] IGET: Mark iget() and read_inode() as being obsolete [try #2] |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
