"Avery Pennarun" <apenwarr@xxxxxxxxx> writes: > 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, > ... > 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. -- 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
