Reproduction and actual results: Commit three revisions that each create a directory: $ mkdir foo $ touch foo/bar $ hg commit -Am "add foo" adding foo/bar $ mkdir bar $ touch bar/bar $ hg commit -Am "add bar" adding bar/bar $ mkdir baz $ touch baz/bar $ hg commit -Am "add baz" adding baz/bar Enter the first directory: $ cd foo Histedit in this manner: $ hg histedit --commands /dev/stdin <<EOF > pick d2d4dc835e6c 1 add bar > pick 94de1676e8e2 0 add foo > fold d0445ab58af5 2 add baz > EOF abort: No such file or directory $ hg histedit --continue d0445ab58af5: cannot fold - working copy is not a descendant of previous commit 3c276c664b93 saved backup bundle to /repo-root/.hg/strip-backup/94de1676e8e2-6431f5f2-histedit.hg $ echo $? 0 $ hg log -T '{rev}:{node|short} {desc}\n' 2:1d3bc4bfc555 fold-temp-revision d0445ab58af5 1:3c276c664b93 add foo 0:db1420950ef0 add bar Expected results: This should have worked, resulting in two revisions, where we first add bar and then add foo and baz together. The failure is also awkward in some ways, like the exit code 0 when --continue fails. Recovery from this point is not obvious, since even the bundle appears to be an intermediate state. I'm guessing this has to do with the baz directory not existing after checking out 3c276c664b93, which causes the initial abort.
Bug was set to UNCONFIRMED for 30 days, bumping
IIRC we did _something_ to rebase to avoid removing $PWD, we should probably do the same in histedit.
Looks like the original reproduction was missing a 'cd' before the `hg histedit --continue`. I'll add a modified version of this test to my tests in https://phab.mercurial-scm.org/D3859.
Fixed by https://mercurial-scm.org/repo/hg/rev/da2a7d8354b2 Kyle Lippincott <spectral@google.com> unlinkpath: make empty directory removal optional (issue5901) (issue5826) There are known cases where performing operations such as rebase from a directory that is newly created can fail or at least lead to being in a directory handle that no longer exists. This is even reproducible by just doing something as simple as: cd foo; hg rm * The behavior is different if you use `hg addremove`, the directory is not removed until we attempt to go back to the node after committing it: cd foo; rm *; hg addremove; hg ci -m'bye foo'; hg co .^; hg co tip Differential Revision: https://phab.mercurial-scm.org/D3859 (please test the fix)
Bug was set to TESTING for 7 days, resolving