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

[Hans Meine]

Hi,

before I discuss Rob's "hg merge -c" proposal, let me quickly mention that 
nowadays, I would use the attic extension for the original problem.  Simple 
issue "hg shelve" (getting a clean working dir), do the merge & commit, and 
"hg unshelve" again.

Now on to Rob's observations:
> In brief, if you don't look at the change _before_ you pull then something
> is probably wrong,

That's right.

> and if you did that then looking extensively at it again
> after you merge seems less likely.

You really might want to test the result before committing, which is "the 
expected hg way".

> Merge seems no more likely to introduce
> bugs than patch "fuzz factor" support is, and I know from personal
> experience that if you implement a patch command without fuzz factor people
> repeatedly poke you to add it.

Good argument.

> Therefore, a "hg merge -c" to auto-commit if there was no mechanically
> detected problem with the merge seems to make sense for the same general
> reason "pull -u" does, and grabbing unrelated changes from your checked-out
> copy of the files seems darn non-orthogonal in what is basically a pure
> repository operation.

Admitted, there are good use cases for "hg merge -c", namely completely 
unrelated changes (e.g. documentation updates merged with code changes, 
changes in unrelated programs within the same repo, etc.), and I would really 
like to see that.  (I wonder why I do not remember having seen this idea 
before here.)

However, IIRC "hg pull -u" is also controversial, I think because it quickly 
becomes a habit to use it, but sometimes people really only want to pull, and 
not merge their working directory with the pulled changesets, and it's not 
easy to roll back here (ATM), since you're fiddling with the working dir.

OTOH, some people planned on adding rollback support for working directory 
changes, too.

Ciao,
  Hans