Subject: Re: Considering teaching plumbing to users harmful

From: Junio C Hamano <[email-masked]>
Date: Wed, 16 Jul 2008 12:34:32 -0700

"Avery Pennarun" <[email-masked]> writes:

> On 7/16/08, Junio C Hamano <[email-masked]> wrote:
>> "Avery Pennarun" <[email-masked]> 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,
> ...
> 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.

I agree in principle, but read what you wrote again and realize that your
criticism does not apply to this case *at all*.

You said svn makes it easier because it makes it very hard to do merges
and forces users to stay away from them.  This results in user doing "svn
update" which is to resolve conflicts with large uncommitted changes but
keeps the history straight single-strand-of-pearls.  

I am not saying the merge based workflow in git does not have any room to
improve.  I am just saying that there is nothing we can learn from svn in
that area.  "Solves it by not letting us to do merges" is not a solution.