Re: GIT vs Other: Need argument

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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.

Needless to say (but I do it nevertheless, since I am in a chatty mood), I 
_never_ can be seen doing the 4-command equivalent of `svn up`. I only 
pull when I have a clean state. (Note: this also leads to a more 
structured way of working, which does prevent errors.)

Ciao,
Dscho