When a user upgrades from mercurial <2.6.3 to >2.7-rc, if they have any old .hg/rebasestate file laying around from an old rebase they forgot to continue, they will get a message suggesting that they run 'hg rebase --abort' as soon as they try to update/commit/etc. rebase --abort then proceeds to wipe all their pending changes, resulting in data loss. Repro: hg init foo cd foo hg book @ echo original > a && hg add a && hg commit -m a echo x > b && hg add b && hg commit -m b1 hg up 0 hg book foo echo y > b && hg add b && hg commit -m b2 hg rebase -d @ -b foo --config ui.merge=internal:merge hg resolve --mark --all # here the users forgets to run hg rebase --continue and keeps working # mv the rebasestate away temporarily so we're allowed to hg up like in mercurial <2.6.3 mv .hg/rebasestate ./ # User does other stuff in the repo hg up -C 0 mv rebasestate .hg/ echo new > a hg up 1 # user upgrades to 2.7 # user gets an error saying to run hg rebase --abort cat a hg rebase --abort cat a # the change in file a is lost
Fixed by http://selenic.com/repo/hg/rev/fe78eb7bcca0 Matt Mackall <mpm@selenic.com> rebase: don't clobber wd on --abort when we've updated away (issue4009) (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/c2a479a058d0 Matt Mackall <mpm@selenic.com> histedit: don't clobber working copy on --abort if not on histedit cset Similar to issue4009, 2.7 will force people to abort histedits before doing interesting things. Without this fix, people with histedit sessions they wandered away from before upgrading to 2.7 could clobber their working copy for no reason. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/01ad8daae5be Jordi Guti?rrez Hermoso <jordigh@octave.org> test-rebase-abort: add test from issue4009 The fix for issue4009, namely fe78eb7bcca0, introduced issue4661. Let's make sure that the fix for issue4661 will not reintroduce issue4009. (please test the fix)
Bug was set to TESTING for 8 days, resolving
Fixed by https://mercurial-scm.org/repo/hg/rev/56d3e0b499df Durham Goode <durham@fb.com> rebase: clear updatestate during rebase --abort in more cases Previously, rebase --abort would only call update if you were on a node that had already been rebased. This meant that if the rebase failed during the rebase of the first commit, the working copy would be left dirty (with a .hg/updatestate file) and rebase --abort would not have update to clean it up. The fix is to also perform an update if you're still on the target node or on the original working copy node (since the working copy may be dirty, we still need to do the update). We don't want to perform an update in all cases though because of issue4009. A subsequent patch makes this case much more common, since it causes the entire rebase transaction to rollback during unexpected exceptions. This causes the existing test-rebase-abort.t to cover this case. (please test the fix)