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 https://hg.mozilla.org/mozilla-central/rev/325acea6a61c 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 ?
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. Graphically: o changeset: 320907:964223d37a2e : tag: tip : user: Jonathan Kingston <email@example.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 <firstname.lastname@example.org> : 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 <email@example.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 <firstname.lastname@example.org> ~ 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.
Filed upstream at https://bz.mercurial-scm.org/show_bug.cgi?id=5415.