If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Merge conflict failed to be detected by hg



Developer Services
Mercurial: hg.mozilla.org
11 months ago
9 months ago


(Reporter: Tomcat, Unassigned)






11 months ago
not sure if this our hg or a general mercurial problem.

Today we had a long time tree closure because of something that looks like a merge conflicts

Problem occured in https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=4f09d9469e73adf32c7db6720504fcbe580516b3 which was the merge from mi->m-c

backed out changes in browser/base/content/browser.js like removing ["URLBarZoom", "resource:///modules/URLBarZoom.jsm"]

but seems something reverted this change and its not clear what or why.

We manually fixed this in https://hg.mozilla.org/mozilla-central/rev/38dcc78edc6dee76a1b8a8ed6c1fd9e3df68fd26

however doing some investigation shows:
Doing a clean clone with the -rev 38fcc30d818f (that was the autoland to m-c merge)
merging m-i to m-c with hg pull ssh://hg.mozilla.org/integration/mozilla-inbound -r 964223d37a2e

result in the problematic lines with still existing ["URLBarZoom", "resource:///modules/URLBarZoom.jsm"]

running hg -v gives:

browser/base/content/browser.js: multiple bids for merge action:
versions differ -> m
versions differ -> m
browser/base/content/browser.js: ambiguous merge - picked m action

there is no indication that there was a problem or merge conflict, so sheriffs had no chance to catch this before.

Gps do you know what was going wrong here and why the changes didn't work and the lines of the code still sayed ?


11 months ago
Flags: needinfo?(gps)

Comment 1

11 months ago

Comment 2

11 months ago
Concise STR:

  $ hg clone -r 38fcc30d818f https://hg.mozilla.org/mozilla-central
  $ cd mozilla-central
  $ hg pull -r 964223d37a2e https://hg.mozilla.org/integration/mozilla-inbound
  $ hg merge 964223d37a2e 
  $ hg commit -m merge

This reproduces the issue for me running Mercurial 4.0+.

It's relevant to look at the state of the DAG wrt browser/base/content/browser.js.

dad84422bcfc (an ancestor of 38fcc30d818f - the future p1 of the merge) introduced the "bad" content.

325acea6a61c (an ancestor of 964223d37a2e - the future p2 of the merge) is a revert of dad84422bcfc.


o  changeset:   320907:964223d37a2e
:  tag:         tip
:  user:        Jonathan Kingston <jkt@mozilla.com>
:  date:        Thu Nov 03 19:31:35 2016 +0100
:  summary:     Bug 1267916 - part 2 - Add in UX for about:preferences#containers page, r=jaws
o  changeset:   320869:325acea6a61c
:  user:        Dão Gottwald <dao@mozilla.com>
:  date:        Thu Nov 03 11:55:04 2016 +0100
:  summary:     Backed out changeset dad84422bcfc (bug 1300376)
: @  changeset:   320810:38fcc30d818f
:/   parent:      320736:3b80868f7a8f
:    parent:      320809:fa679b6eced2
:    user:        Phil Ringnalda <philringnalda@gmail.com>
:    date:        Thu Nov 03 19:24:04 2016 -0700
:    summary:     Merge autoland to m-c, a=merge
o  changeset:   320434:dad84422bcfc
|  user:        Jared Wein <jwein@mozilla.com>
~  date:        Tue Nov 01 15:25:06 2016 -0400
   summary:     Bug 1300376 - Update the zoom indicator status on XULBrowserWindow location changes to catch cases where the indicator wasn't getti

There are also changesets 320863:309e32ebbc3a, 320864:822379ac9dbb (ancestors of 325acea6a61c) and 320899:f19157ac2e48, 320900:ab12ade75727 (between 325acea6a61c and future p2 964223d37a2e) that also modified browser.js. However, they didn't touch the lines in question.

Looking at the shape of the DAG alone, it certainly feels buggy that 325acea6a61c from the p2 head wasn't incorporated in the final merge. I dare say this is a bug in Mercurial's merge algorithm. I'll file something upstream.
Flags: needinfo?(gps)

Comment 3

11 months ago
Filed upstream at https://bz.mercurial-scm.org/show_bug.cgi?id=5415.
QA Contact: hwine → klibby
You need to log in before you can comment on or make changes to this bug.