A tale of user-friendliness with "hg merge" and "hg rollback".

[Masklinn]

On 12 Oct 2009, at 23:23 , Rob Landley wrote:
>
> I still don't understand what an uncommitted merge commit _means_,  
> or why such
> a halfway state would exit.
See Yann's answer: merges don't self-commit, because they might be  
wrong (one of the default ideas in DVCS is that merges should be easy  
but are still hard, so DVCS very explicitly try to be dumb in merges —  
while including as much information as possible — in order to not  
break your stuff).

So the role of un-commited merges is to let you test that the result  
of the merge *does* actually work. It lets you retouch that result if  
need be (sometimes you need a bit of fixing to get a correct merge,  
even if the tool was "able" to create a merge changeset on its own)

> Or why it needs a merge commit to fix up a one line change in an  
> area I hadn't touched in ages.

Because that one line change is in its own changeset, which creates  
its own history, which diverges from the history *you* have in your  
repository.

Basically, you get this:

o
|\
| |
| |

Even if one of those only changed a single line, as far as the tool's  
concerned they're still two (un-named) branches. The tool's not going  
to guess that they're compatible (see above, it tries very hard to be  
very dumb about that stuff, because if it's clever it's going to break  
your code; also note that this issue is specific to the changeset  
model, it might be different with patch-based models such as Darcs's).  
So the tool wants you to tell it "these two branches are compatible,  
and they fit together this way" (which might be complex, or might be  
trivial, but that's your judgement). And that's what a merge changeset  
does.

It goes from

o
|\
| |
| |

to

o
|\
| |
| |
|/
o