Re: GIT vs Other: Need argument

> Hi,
>
> On Thu, 19 Apr 2007, Jakub Narebski wrote:
>
>> Steven Grimm wrote:
>>
>>> One can argue about whether allowing partial commits like that is a
>>> good idea, but it's just not true that svn forces you to always update
>>> before you commit, and if you're pushing into a branch that other
>>> people are also updating, the ability to commit files that didn't
>>> change upstream means it is actually *less* insistent on
>>> update-then-commit than git is (if you take "commit" to mean
>>> "commit-and-push" on the git side as was suggested in the message I
>>> replied to originally.)
>>>
>>> Unless, of course, I'm misinterpreting you here.
>>
>> I just think the commit _then_ merge (or commit-then-update) workflow is
>> much, much better than update-then-commit one.
>
> Let me pick up the ball here. Once you did your share of conflicting
> merges, you _will_ realize how much better it is to merge when you are at
> a relatively stable state, i.e. you can test things (if only to make sure
> that the merge did not introduce strange side effects). And guess what, at
> such a stage I would commit anyway.
>
> It is so much easier to resolve conflicts if you can look at both sides,
> and can actually go to both sides to test things out, or even just
> generate the diff to one side. This is just not possible with a dirty
> merge. Exactly because you knowingly lost the current state, you cannot do
> diffs with it.