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

[Dennis Brakhane]

(Forgot to cc the list)


On Mon, Oct 12, 2009 at 11:23 PM, Rob Landley <rob at landley.net> wrote:
> I still don't understand what an uncommitted merge commit _means_, or why such
> a halfway state would exit.  Nor why it tries so hard to involve the current
> working store in pulling somebody else's repository.  Or why it needs a merge
> commit to fix up a one line change in an area I hadn't touched in ages.

If you merge, Mercurial tries to merge all changes in both parents
together. But even if this
succeeds, Mercurial has know way of determing whether the merge is
still correct. Consider
the following (contrived) example:

The original foo.c contains code like this:

void barfoo(void* baz) {

 do_something_with(baz);
 do_something_else();

}

Now your friend fixes a memory leak:

...
 do_something_with(baz);
+free(baz); // Friend: fix memory leak
 do_something_else();

You, fix it too and add functionality:

...
 do_something_else();
+do_something_really_cool(baz);
+free(baz); // Fix leak

Both commits are valid, but the merge result, even though it applies
cleanly, is not:

vod barfoo(void* baz) {
 do_something_with(baz);
 free(baz); //Friend: fix memory leak
 do_something_else();
 do_something_really_cool(baz);
 free(baz); // Fix leak
}

Not only will do_something_really_cool now probably segfault (possibly
in a really cool way), even if
it doesn't, you have a nasty double free.

This is why a merge happens in your working store (which should be
clean before you merge).
Mercurial tries it's best to merge, but afterwards, you have to
confirm that the merge still makes sense.
If it does, you commit it. If it doesn't, you fix it, and then commit.
Just because Subversion merges silently doesn't
mean it's a wise thing to do.

But I agree with you that the usability of merge could be improved,
it's easier to shoot yourself in the foot that it
should be