Re: GIT vs Other: Need argument

Johannes Schindelin wrote:

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.
  

That's a great workflow if you're working on relatively discrete, 
standalone changes. A lot of the time, when I'm working on an isolated 
change, I do just that, and I merge when I'm stable just like you 
describe. That's probably the vastly most common mode of operation for 
distributed open-source projects, which obviously were git's initial 
target audience.

However, it is frequently NOT the mode of operation for development at a 
company where two or more people are working on implementing the same 
new feature in a highly collaborative way, often sitting across the room 
from one another. In that situation, it's frequently the case that, for 
example, I'm coding and discover I need some new utility method that Joe 
can easily factor out of the code he just checked in. So he does his 
quick refactoring, commits that change, and I pull it into my sandbox 
where I am *not* yet at a stable stopping point because I was waiting 
for his change in order to finish and/or test my change. Or, more 
commonly, I discover a bug in his code and he checks in a fix I want to 
pick up.

That's the use case for dirty working-copy merges. It is extremely 
common in my experience. Actually I can't think of a single company I've 
worked at in ~20 years of professional programming, from huge ones to 
small startups, where that wasn't a frequent working style, especially 
during crunch times or initial implementation.

The XP people even have a name for it: "continuous integration." 
(Granted, that's not *exactly* what that term means, but "update early 
and often" is a pretty important part of the CI workflow.)

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.
  

I don't disagree, but that's only an issue given the underlying 
assumption that you will be integrating only occasionally, and thus will 
tend to pull massive numbers of changes with lots of conflicts. If you 
know there will be at most one or two conflicts (or more likely none at 
all) because your last pull was twenty minutes ago and there have only 
been three other pushes since then, it's not an issue. That's the 
typical situation in a continuous-integration shop. I'd say 95% -- to be 
ridiculously conservative -- of the "svn up" commands that are run at my 
company result in no conflicts at all.

When a large conflict is a once-every-couple-of-months event because 
you've resolved all the trivial conflicts as they've appeared along the 
way, optimizing your daily workflow for the "what if I need to resolve a 
big hairy conflict?" case just doesn't make much sense.

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.)
  

And out of curiosity, are you using git for distributed, relatively 
autonomous development, or for collaboration with a high level of 
interdependency between developers?

-Steve