Sorry for the horrible title. I was bisecting an issue and hit a merge of inbound -> central . Note the oldest entry is a backout. It then tries to get the range from inbound  which ends up with an EmptyPushlogError. If I adjust the range to start from the next newer change things work . So either this is a mozregression bug or possibly an hgweb bug.  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d700dc054751333e0735f975fce3d3adf153c62a&tochange=bcf4ff0c3eef498cd853a88270c75c161e524549  https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=4a860475d96a0f7705106498e7380debc7fb2ab9&tochange=633d41ede644bf0fed6ca98328168d9c8f44c1de  https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=6b0802bc324c&tochange=633d41ede644
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.)
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
Summary: mozregression fails to transition to branch when bisecting a range that starts with a backout → mozregression fails to transition to branch when bisecting a merge push that starts with a direct-to-central landing
You need to log in before you can comment on or make changes to this bug.