Bug 5826 - after re-ordering removes a directory, histedit aborts and cannot --continue
Summary: after re-ordering removes a directory, histedit aborts and cannot --continue
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: histedit (show other bugs)
Version: 4.5
Hardware: PC Linux
: wish bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-22 16:15 UTC by Danny Hooper
Modified: 2018-07-11 00:00 UTC (History)
3 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Danny Hooper 2018-03-22 16:15 UTC
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.
Comment 1 Bugzilla 2018-04-22 00:00 UTC
Bug was set to UNCONFIRMED for 30 days, bumping
Comment 2 Bugzilla 2018-05-23 00:00 UTC
Bug was set to UNCONFIRMED for 30 days, bumping
Comment 3 Augie Fackler 2018-06-01 02:24 UTC
IIRC we did _something_ to rebase to avoid removing $PWD, we should probably do the same in histedit.
Comment 4 Kyle Lippincott 2018-06-28 21:32 UTC
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.
Comment 5 HG Bot 2018-07-03 12:05 UTC
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)
Comment 6 Bugzilla 2018-07-11 00:00 UTC
Bug was set to TESTING for 7 days, resolving