[Bug 4476] New: Graft copy tracing loses log -f history
mercurial-bugs at selenic.com
mercurial-bugs at selenic.com
Thu Dec 18 19:35:02 UTC 2014
http://bz.selenic.com/show_bug.cgi?id=4476
Priority: normal
Bug ID: 4476
CC: mercurial-devel at selenic.com
Assignee: bugzilla at selenic.com
Summary: Graft copy tracing loses log -f history
Severity: bug
Classification: Unclassified
OS: Mac OS
Reporter: durham at fb.com
Hardware: PC
Status: UNCONFIRMED
Version: 3.2.2
Component: Mercurial
Product: Mercurial
Grafting a mv with edits over an existing mv with different edits causes the
log -f history to not show the second edit.
hg init foo
cd foo
touch a && hg ci -Aqm a
hg mv a b
echo b1 >> b
hg ci -Aqm b1
hg up 0
hg mv a b
echo b2 >> b
hg ci -Aqm b2
hg graft 1
hg log -f b
Expected:
changeset: 3:1edcf609cbb7
summary: b1
changeset: 2:d98d3276e1cd
summary: b2
changeset: 0:01f02e8249d2
summary: a
Actual:
changeset: 3:1edcf609cbb7
summary: b1
changeset: 0:01f02e8249d2
summary: a
This is caused by localrepo._filecommit attempting to find copy information by
traversing the commit graph in search of the last place that had the source
file. It finds the original 'a' commit and makes that the filelog parent of the
incoming change.
The entire localrepo._filecommit() copy tracing logic is broken. For example:
The look up is 'self[None].ancestors()' but localrepo._filecommit is called
from commitctx which is totally independent of the working copy. So arbitrary
memctx commits are doing copy tracing relative to the working copy position.
In my opinion we should not be doing any copy tracing at all here. If the copy
source file is not in either of the parent manifests, it's not a copy. If
graft wants to be smart about importing copies, that logic should exist in
graft/merge and it should set up the dirstate appropriately before committing.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Mercurial-devel
mailing list