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