[Bug 4661] New: rebase --abort does not reset state properly

mercurial-bugs at selenic.com mercurial-bugs at selenic.com
Sun May 10 01:16:31 CDT 2015


          Priority: normal
            Bug ID: 4661
                CC: mercurial-devel at selenic.com
          Assignee: bugzilla at selenic.com
           Summary: rebase --abort does not reset state properly
          Severity: bug
    Classification: Unclassified
                OS: Other
          Reporter: jwdevel at gmail.com
          Hardware: PC
            Status: UNCONFIRMED
           Version: 3.4-rc
         Component: rebase
           Product: Mercurial

Under fairly normal usage, `hg rebase --abort` does not reset the state of
things back to how it was before the rebase started.

Also, the documentation for `--abort` could perhaps be improved. The
commandline docs merely say "abort an interrupted rebase", though the wiki docs
say "restoring the repository to its original state"

Here are repro steps:

    hg ini rebase-abort-bug
    cd rebase-abort-bug
    echo "initial data" > foo.txt
    hg add
    hg ci -m "initial checkin"
    echo "change 1" > foo.txt
    hg ci -m "change 1"
    hg up 0
    echo "conflicting change 1" > foo.txt
    hg ci -m "conflicting 1"
    echo "conflicting change 2" > foo.txt
    hg ci -m "conflicting 2"

    hg resolve -l
# We see empty output, as expected

    hg rebase -d 1 --tool 'internal:fail'
# The rebase fails - it could have failed even if we
# didn't use 'internal:fail', since there are conflicts.
    hg rebase --abort
    hg resolve -l

# Here, we get output "U foo.txt", indicating there
# is a resolve in progress.
# Further, `hg log -G` shows two "@" parents (merge in progress)

# Also, perhaps this is a separate bug, but `hg status` shows
# "M foo.txt" even though `hg diff` gives no output.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Mercurial-devel mailing list