On 7/16/08, Junio C Hamano <gitster@pobox.com> wrote:
quoted text
> "Avery Pennarun" <apenwarr@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html