On 7/16/08, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Avery Pennarun" <apenwarr@xxxxxxxxx> writes: > > svn avoids these excess merges by default, albeit because it puts your > > working copy at risk every time you do "svn update". > > By default? As if it has other mode of operation. > > Of course if you do not allow any commits in between to make the history > truly forked, you won't see merge commits. It is like saying that you > like your broken keyboard whose SHIFT key does not work because you think > capital letters look ugly and your keyboard protects you from typing them > by accident. > > Is that an improvement? > > I won't waste my time further on the apples and rotten oranges comparison, I find it interesting how git usability discussions tend to go. It usually starts out by someone saying, "Look, git really isn't that hard to learn, just do it like this..." and then someone says, "But actually, that's still really complicated. Everyone thinks xxx other VCS is easier to learn. Here's how they do it..." And then someone says, "Yeah, but xxx VCS sucks!" and that somehow makes it okay that git is empirically harder to learn than xxx VCS, as anyone can see by browsing the web. svn is fundamentally broken, but just because they did *some* things wrong doesn't mean they did *everything* wrong. You can learn lessons even from your inferiors. Have fun, Avery -- 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
