$ cat >> $HGRCPATH << EOF > [extensions] > fsmonitor = > rebase = > EOF $ hg init repo $ cd repo $ echo c0 >> a $ echo c0 >> b $ hg add a b $ hg ci -m c0 $ echo c1 >> a $ hg ci -m c1 $ hg up .^ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo c2 >> a $ echo c2 >> b $ hg ci -m c2 created new head Merge tool that runs status in between, triggering the race. $ cat >> $TESTTMP/mergetool.sh << EOF > echo "custom merge tool" > printf "c0\nc1\nc2\n" > \$1 > hg --cwd $TESTTMP/repo status > EOF $ cat >> $HGRCPATH << EOF > [merge-tools] > test.executable=sh > test.args=$TESTTMP/mergetool.sh \$output > EOF $ hg rebase -s . -d 1 --tool test $ hg log -p --debug $ hg status That last 'hg status' should be empty, but it returns 'M b'.
Note that reproducing this on default requires applying 'match: introduce nevermatcher for when no ignore files are present', which I've sent to the mailing list.
Closely related to bug 5584.
Fixed by https://www.mercurial-scm.org/repo/hg/rev/15e85dded933 and https://www.mercurial-scm.org/repo/hg/rev/1b25c648d5b7.
Bug was set to TESTING for 7 days, resolving
Fixed by https://mercurial-scm.org/repo/hg/rev/2083d1643d69 Siddharth Agarwal <sid0@fb.com> workingctx: add a way for extensions to run code at status fixup time Some extensions like fsmonitor need to run code after dirstate.status is called, but while the wlock is held. The extensions could grab the wlock again, but that has its own peculiar race issues. For example, fsmonitor would not like its state to be written out if the dirstate has changed underneath (see issue5581 for what can go wrong in that sort of case). To protect against these sorts of issues, allow extensions to declare that they would like to run some code to run at fixup time. fsmonitor will switch to using this in the next patch in the series. (please test the fix)
Bug was set to TESTING for 10 days, resolving