Bug 4251 - histedit folding commits results in conflict
Summary: histedit folding commits results in conflict
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: histedit (show other bugs)
Version: 3.0
Hardware: PC Windows
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-16 07:10 UTC by Cristian Vasile Mocanu
Modified: 2015-12-23 00:00 UTC (History)
5 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 Cristian Vasile Mocanu 2014-05-16 07:10 UTC
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.
Comment 1 Pierre-Yves David 2014-06-23 06:56 UTC
I can reproduce this with the provided script.

Sounds like a rename handling bug in histedit.
Comment 2 Cristian Vasile Mocanu 2014-06-23 09:12 UTC
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.
Comment 3 Augie Fackler 2015-01-16 15:45 UTC
This was fixed a while ago (probably by marmoute), I'm going to push a test for it.
Comment 4 HG Bot 2015-01-16 17:15 UTC
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)
Comment 5 Bugzilla 2015-01-25 16:52 UTC
Bug was set to TESTING for 8 days, resolving
Comment 6 HG Bot 2015-12-15 18:15 UTC
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)
Comment 7 Bugzilla 2015-12-23 00:00 UTC
Bug was set to TESTING for 7 days, resolving