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

[Rob Landley]

On Monday 12 October 2009 16:52:36 Masklinn wrote:
> 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

I wrote a long reply to Dennis Brakhane about this, but it turns out his 
message was private and not cc'd to the list.

In brief, if you don't look at the change _before_ you pull then something is 
probably wrong, and if you did that then looking extensively at it again after 
you merge seems less likely.  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.  (And in both cases, you can fix the problem in a new commit, 
once you spot it.)

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.

But that's just my opinion.

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

Explicitly trying to be dumb is one thing.  This was a one-line commit to a 
file that didn't have any changes within a dozen lines of that commit, a case 
where exporting a diff and applying it as a patch would have worked just fine.  
What surprised me was mercurial being dumber than diff/patch.

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

And in future I know to go back to "hg export" and "hg import" rather than 
trying to pull.  This was a learning experience for me.  (I attended Matt's 
OLS talk on mercurial in 2006, and the BOF, and _five_ different git talks, and 
bothered Junio Hamano about it trying to decide between git and mercurial.  
You really don't have to start drawing graphs for me.)

Most of the actual fiddling with branches I've done has been in git, and I 
thought both that mercurial had an equivalent of "fast forward" merging and 
that the technique could handle more cases than it did.  Since "hg export/hg 
import" doesn't need to produce a merge commit, I didn't think this did 
either.  I was wrong.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds