Closed Bug 1412134 Opened 4 years ago Closed 4 years ago

mach try complains about uncommit changes even though actually it has no uncommit changes

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox58 fixed)

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: emk, Assigned: ahal)

Details

Attachments

(1 file)

$ hg commit --amend
saved backup bundle to e:\m\mozilla-unified\.hg\strip-backup/db952c16d996-f5ff9da7-amend.hg
warning: ignoring unknown working parent 78ba3ef5070d!

$ mach try -b do -p linux64 -u all -t none
ERROR please commit changes before continuing

$ hg commit
nothing changed

$ mach try -b do -p linux64 -u all -t none
Creating temporary commit for remote...
pushing to ssh://hg.mozilla.org/try
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 37 changes to 37 files (+1 heads)
remote: recorded push in pushlog
remote:
remote: View your changes here:
remote:   https://hg.mozilla.org/try/rev/78ba3ef5070dd545ea058ce4acd172c586261d0e
remote:   https://hg.mozilla.org/try/rev/e11ca6d6a4bbc52612ca6157b83c07790701dbd6
remote:
remote: Follow the progress of your build on Treeherder:
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=e11ca6d6a4bbc52612ca6157b83c07790701dbd6
remote: recorded changegroup in replication log in 0.038s
push complete
temporary commit removed, repository restored

I have to run `hg commit` and see `nothing changed` to satisfy `mach try`. Why?
Even worse, sometimes `hg commit` does not workaround the issue. I had to create an empty changeset and remove it using mq:

$ mach try -b do -p linux64 -u all -t none
ERROR please commit changes before continuing

$ hg commit
nothing changed

$ mach try -b do -p linux64 -u all -t none
ERROR please commit changes before continuing

$ hg qnew tmp && hg qpop -a && hg qrm tmp
popping tmp
patch queue now empty

$ mach try -b do -p linux64 -u all -t none
Creating temporary commit for remote...
pushing to ssh://hg.mozilla.org/try
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 11 changes to 39 files (+1 heads)
remote: recorded push in pushlog
remote:
remote: View your changes here:
remote:   https://hg.mozilla.org/try/rev/73e833e6258320d8b241e334b0d860013b96c15d
remote:   https://hg.mozilla.org/try/rev/7359f448be2af41c059dd93f4f1c720db2d05381
remote:
remote: Follow the progress of your build on Treeherder:
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=7359f448be2af41c059dd93f4f1c720db2d05381
remote: recorded changegroup in replication log in 0.036s
push complete
temporary commit removed, repository restored
I hit this recently. I added some debug logging to http://searchfox.org/mozilla-central/rev/21363323fd4aa21db074c808fb5358a46df6d698/tools/tryselect/vcs.py#163 to see what the stray output was (it was a small issue in my hgrc file).

It looks like bug 1384593 made us a bit more susceptible to this (although the old approach wasn't amazing). Andrew, is this something you could take a look at?
Flags: needinfo?(ahalberstadt)
Instead of prohibiting uncommitted working directory changes, I think we should issue a warning and include them in the Try push. We could do this with our custom push-to-try hg extension.

Alternatively, we could leverage `hg shelve` to stash aside the working directory changes and push a "clean" commit.

Behavior could be controlled via a flag/default.
(In reply to Chris Manchester (:chmanchester) from comment #2)
> It looks like bug 1384593 made us a bit more susceptible to this (although
> the old approach wasn't amazing). Andrew, is this something you could take a
> look at?

Do you have an idea how to reproduce this? I'd be happy to take it, though not sure what the problem is (or how to fix it). Could you paste the debug logs you added?


(In reply to Gregory Szorc [:gps] from comment #3)
> Instead of prohibiting uncommitted working directory changes, I think we
> should issue a warning and include them in the Try push. We could do this
> with our custom push-to-try hg extension.

I like this idea. Depending on what's involved in fixing this, might be better to tackle it in a follow-up.
Flags: needinfo?(ahalberstadt)
If hg or an extension prints something when we run `hg status -amrn` that gets interpreted as a change we want to reject. In my case the output was something like "mqext is mostly disabled when mq is not installed", in the case of comment 0 it seems like "warning: ignoring unknown working parent 78ba3ef5070d!".
Good catch, my mistake. This is happening because we're redirecting stderr to stdout for some reason, definitely shouldn't be doing that and I'll fix it here.

But we should really move this logic into mozversioncontrol. I'll file a follow-up for that and for tackling gps' idea.
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
(In reply to Chris Manchester (:chmanchester) from comment #5)
> in the
> case of comment 0 it seems like "warning: ignoring unknown working parent
> 78ba3ef5070d!".

By the way, why do I get this error whenever I run `hg commit --amend`, `hg rebase`, etc.? Is my mercurial repository broken somehow?
Comment on attachment 8923573 [details]
Bug 1412134 - [tryselect] Redirect stderr to a separate pipe,

https://reviewboard.mozilla.org/r/194708/#review199798

Thanks!
Attachment #8923573 - Flags: review?(cmanchester) → review+
Pushed by ahalberstadt@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ddaa6cbd666e
[tryselect] Redirect stderr to a separate pipe, r=chmanchester
https://hg.mozilla.org/mozilla-central/rev/ddaa6cbd666e
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.