What went wrong in this trivial merge? - mercurial

Question

Edit: This certainly isn't good practice on stackoverflow and I sincerely apologize, but as it seems I was very unclear about the exact steps I was doing, causing confusion. Therefore I decided to rewrite the post and make it more clear which exact commands I was running and in what order to reproduce my experience.
Because I had to deal with bogus merges in Mercurial before, I did a little experiment:
cd example
hg init
create example.dart
num add(num a, num b) {
return a - b;
}
hg add .\example.dart
hg commit -m "bogus add()"
hg branch other
add to example.dart:
num sub(num a, num b) {
return a - b;
}
hg commit -m "correct sub()"
hg update default
hg commit -m "fix add()"
(note by me: Mercurial messes up some characters)
hg log -G
# ─nderung: 2:19a3c127981b
| Marke: tip
| Vorgõnger: 0:ac1d30ac2dda
| Nutzer: Marvin
| Datum: Mon Jul 01 19:31:24 2019 +0200
| Zusammenfassung: fix add()
|
| o ─nderung: 1:645416c58a38
|/ Zweig: other
| Nutzer: Marvin
| Datum: Mon Jul 01 19:23:40 2019 +0200
| Zusammenfassung: correct sub()
|
o ─nderung: 0:ac1d30ac2dda
Nutzer: Marvin
Datum: Mon Jul 01 19:19:47 2019 +0200
Zusammenfassung: bogus add()
hg update other
hg graft 19a3c127981b
hg log -G
# ─nderung: 3:567c99a23b17
| Zweig: other
| Marke: tip
| Vorgõnger: 1:645416c58a38
| Nutzer: Marvin
| Datum: Mon Jul 01 19:31:24 2019 +0200
| Zusammenfassung: fix add()
|
| o ─nderung: 2:19a3c127981b
| | Vorgõnger: 0:ac1d30ac2dda
| | Nutzer: Marvin
| | Datum: Mon Jul 01 19:31:24 2019 +0200
| | Zusammenfassung: fix add()
| |
o | ─nderung: 1:645416c58a38
|/ Zweig: other
| Nutzer: Marvin
| Datum: Mon Jul 01 19:23:40 2019 +0200
| Zusammenfassung: correct sub()
|
o ─nderung: 0:ac1d30ac2dda
Nutzer: Marvin
Datum: Mon Jul 01 19:19:47 2019 +0200
Zusammenfassung: bogus add()
This produces the expected result in example.dart:
num add(num a, num b) {
return a + b;
}
num sub(num a, num b) {
return a - b;
}
hg update default
hg merge other
hg commit -m "merge with other"
hg log -G
# ─nderung: 4:a76695f39931
|\ Marke: tip
| | Vorgõnger: 2:19a3c127981b
| | Vorgõnger: 3:567c99a23b17
| | Nutzer: Marvin
| | Datum: Mon Jul 01 19:37:18 2019 +0200
| | Zusammenfassung: merge with other
| |
| o ─nderung: 3:567c99a23b17
| | Zweig: other
| | Vorgõnger: 1:645416c58a38
| | Nutzer: Marvin
| | Datum: Mon Jul 01 19:31:24 2019 +0200
| | Zusammenfassung: fix add()
| |
o | ─nderung: 2:19a3c127981b
| | Vorgõnger: 0:ac1d30ac2dda
| | Nutzer: Marvin
| | Datum: Mon Jul 01 19:31:24 2019 +0200
| | Zusammenfassung: fix add()
| |
| o ─nderung: 1:645416c58a38
|/ Zweig: other
| Nutzer: Marvin
| Datum: Mon Jul 01 19:23:40 2019 +0200
| Zusammenfassung: correct sub()
|
o ─nderung: 0:ac1d30ac2dda
Nutzer: Marvin
Datum: Mon Jul 01 19:19:47 2019 +0200
Zusammenfassung: bogus add()
The history now looks like expected. However, the merge result does not:
num add(num a, num b) {
return a + b;
}
num sub(num a, num b) {
}
Interestingly the merge algorithm cleanly cuts out the body of sub() while not producing any conflicts.
The experiment was done on a Windows 10 machine with a freshly installed Mercurial 4.9.1. The only installed diff-tool is KDiff3 which comes with Mercurial and TortoiseHg (which I didn't use). Standard settings weren't changed and no plugins were activated.
Maybe this is just some weird corner case, though I would be very interested in what causes it. I would be very happy for any insight you could give. Bogus merges like this cause enormous headaches, hence I think this is relevant.

Answer 1

I cannot reproduce your experience. Here is my attempt:
$ mkdir hg
$ cd hg
$ hg init
$ cat > exp.lang << 'end'
> num add(num a, num b) {
> return a - b;
> }
> end
$ hg add exp.lang
$ hg commit -m initial
$ hg branch other
marked working directory as branch other
(branches are permanent and global, did you want a bookmark?)
$ cat >> exp.lang << 'end'
>
> num sub(num a, num b) {
> return a - b;
> }
> end
$ hg commit -m 'add sub()'
$ hg checkout default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ed exp.lang
42
2
return a - b;
s/-/+/
w
42
q
$ hg commit -m 'fix bug'
As far as I can tell, this is what you said you did: fix the bug on the default branch. Let's graft the fix and see if it looks right:
$ hg checkout other
$ hg graft -r 2
grafting 2:2670b3299c96 "fix bug" (tip)
merging exp.lang
$ hg lga # lga is a graphical log alias
# 3:811f4d1a7dc4:draft other tip Chris Torek
| fix bug (54 seconds ago)
|
| o 2:2670b3299c96:draft Chris Torek
| | fix bug (54 seconds ago)
| |
o | 1:a780b1c8c579:draft other Chris Torek
|/ add sub() (112 seconds ago)
|
o 0:b085834fc520:draft Chris Torek
initial (3 minutes ago)
$ cat exp.lang
num add(num a, num b) {
return a + b;
}
num sub(num a, num b) {
return a - b;
}
So far, so good - as far as I can tell, I have reproduced your setup. Now:
$ hg checkout default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge other
warning: conflicts while merging exp.lang! (edit, then use 'hg resolve --mark')
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon
The merge failed because Mercurial needs human help. Here's what Mercurial saw:
$ cat exp.lang
num add(num a, num b) {
<<<<<<< working copy
return a + b;
||||||| base
return a - b;
=======
return a + b;
}
num sub(num a, num b) {
return a - b;
>>>>>>> merge rev
}
The base copy of the file, from revision 0, has the bug: add returns a - b. The tip of the current (default) branch, version 2, looks like this:
$ hg abort
aborting the merge, updating back to 2670b3299c96
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat exp.lang
num add(num a, num b) {
return a + b;
}
which is what we should expect: the bug is fixed. The revision we're merging in has the same one-line fix, but also inserts all this other stuff—four extra lines—before the final close brace. Which one should the VCS use, the one line fix or the five line fix? It doesn't know, so it stops to get help.

Answer 2

Mercurial (TortoiseHG) 4.9.1, the same result as #torek wrote
THG's version of failed merge
% hg merge --config=ui.merge=:merge --verbose 3
resolving manifests
merging functions.c
warning: conflicts while merging functions.c! (edit, then use 'hg resolve --mark')
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon
and (expected) state of the file in the middle of process (immediately after the above merge)
num add(num a, num b) {
return a + b;
<<<<<<< working copy
=======
}
num sub(num a, num b) {
return a - b;
>>>>>>> merge rev
}
Addition
This merge can't be non-conflicting merge for usual merge-tools (GUI presentation will be better here)
because grey string /(1) om screenshot/ in merge-result IS conflicted area, which (conflict) have to be resolved in any way. But, if we supposing after observing "other" file (right-side of merge-panel, (2) area on screenshot) and your described result
num sub(num a, num b) {
}
that your default merge-tool can be tool, which dictate own policy, not resolving, it can be answer on question "Why it happened".
Slightly more deep: if your default merge-tool is somehow "internal:other", then
Green Section (2) from "other side" have to appear in merge-result (as requested by selecting mergetool)
Conflict-area (1) just ignored
Closing bracket } (3) is common hunk for both sides of merge and transferred to merge-result