1286039 - mozregression fails to transition to branch when bisecting a merge push that starts with a direct-to-central landing

Status: RESOLVED WONTFIX

(Testing :: mozregression, defect)

Description

[Eric Rahm [:erahm]]

Sorry for the horrible title. I was bisecting an issue and hit a merge of inbound -> central [1].

Note the oldest entry is a backout. It then tries to get the range from inbound [2] which ends up with an EmptyPushlogError. If I adjust the range to start from the next newer change things work [3].

So either this is a mozregression bug or possibly an hgweb bug.

[1] https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d700dc054751333e0735f975fce3d3adf153c62a&tochange=bcf4ff0c3eef498cd853a88270c75c161e524549
[2] https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=4a860475d96a0f7705106498e7380debc7fb2ab9&tochange=633d41ede644bf0fed6ca98328168d9c8f44c1de
[3] https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=6b0802bc324c&tochange=633d41ede644

Comment 1

[Ian Moody [:Kwan] (UTC+1)]

So I think the actual issue here is that the bottom-most rev in the push is something that landed on m-c directly, rather than being a backout specifically.  As a result it doesn't end up on inbound until the next merge back, and is thus _after_ the tochange rev 633d41ede644 in inbound's.
So the problem is with any push where the m-c graph log looks something like this made-up example:

@  - 987fef0d - merge m-i to m-c                ▔▔\
|\                                                |
| |                                               |
| o - a9d876cb - 2nd change on m-i, merge cand.   |
| |                                               }-- the changes in the merge push
| o - 9864e952 - change on m-i                    |
| |                                               |
| ~                                               |
o - 8ac4007d - change on m-c                    ▁▁/
|                                               
o - deadbeef - pre-merge m-c tip
|
~ 

I'm not sure if there is a good way to handle this in mozregression.  Maybe fetching the revs and checking their parents, and ignoring ones that aren't parents of the next rev when constructing the inbound query (and probably only doing that work if the usual method already returned an empty pushlog).  However chatting to Aryx on IRC it appears this pattern ("pushing more than the merge") should be avoided, specifically because it can confuse tools, so I don't think it's worth doing so on the assumption that such pushes should be rare.  Marking the bug WONTFIX as a consequence, but feel free to disagree.
(It would have been nice to programatically query the pushlog data to verify this, but as it's a Mozilla extension rather than a base part of Mercurial this doesn't seem easy to do.)