Folding commits with the histedit extension results in conflict. Here is the test case: 1) Initialize an new repo: > $ hg init 2) Create a file: > $ mkdir initial-dir ; echo foo > initial-dir/initial-file ; hg add initial-dir/initial-file ; hg commit -m "initial commit" 3) Move the file to a new directory, and in the same commit, change its content: > $ mkdir another-dir ; hg mv initial-dir/initial-file another-dir/ ; echo changed > another-dir/initial-file ; hg commit -m "moved and changed" 4) Rename the file: $ hg mv another-dir/initial-file another-dir/renamed-file ; hg commit -m "renamed" 5) Now, let's try to fold the second commit into the first: > $ hg histedit --rev "draft()" Choosing to fold in the editor: > pick 6ed6458efaa6 0 initial commit > fold 652030fdfb10 1 moved and changed > pick 13e1a480f2a7 2 renamed histedit outputs this: > 1 files updated, 0 files merged, 1 files removed, 0 files unresolved > adding another-dir\initial-file > removing initial-dir\initial-file > 0 files updated, 0 files merged, 1 files removed, 0 files unresolved > 1 files updated, 0 files merged, 0 files removed, 0 files unresolved > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved > local changed another-dir/initial-file which remote deleted > use (c)hanged version or (d)elete? I assume the conflict arises when it tries to apply the third commit. The expected behavior is so have the file in the same state as if I had 3 commits (before the fold), namely: - the content of the file should be "changed" - the name of the file should be "another-dir/renamed-file" And of course, I don't expect conflicts, since folding 2 commits means by definition: create one commit which is performs the same changes as the folded commits - so I don't see any possibility for conflicts. hg version outputs: > Mercurial Distributed SCM (version 3.0+3) I'm using Windows 8.1 64bit.
I can reproduce this with the provided script. Sounds like a rename handling bug in histedit.
I suspect this is a bug in how mercurial handles merges with renames (rather than a bug in histedit), but I didn't check any code so I may be wrong.
This was fixed a while ago (probably by marmoute), I'm going to push a test for it.
Fixed by http://selenic.com/repo/hg/rev/3831e9b3750a Augie Fackler <raf@durin42.com> histedit: add a test to show that issue4251 is fixed (issue4251) This will help us not regress this case in the future. (please test the fix)
Bug was set to TESTING for 8 days, resolving
Fixed by https://selenic.com/repo/hg/rev/5b68f72c2ba9 timeless <timeless@mozdev.org> tests: relax histedit issue4251 and issue3893 backups I'm globbing these because some are globbed, and this pair gets in the way of the main parts of the series. (please test the fix)
Bug was set to TESTING for 7 days, resolving