https://bz.mercurial-scm.org/show_bug.cgi?id=5834
Bug ID: 5834
Summary: If a grafted file is renamed, subsequent grafts fail
to find it
Product: Mercurial
Version: 4.1.1
Hardware: PC
OS: Windows
Status: UNCONFIRMED
Severity: bug
Priority: normal
Component: Mercurial
Assignee: bugzi...@mercurial-scm.org
Reporter: gabor.stefa...@nng.com
CC: mercurial-devel@mercurial-scm.org
Consider the following script:
$ hg init
$ echo a > a; hg add a
$ hg commit -m a # creates revision 0 as the root
$ echo b > b; hg add b
$ hg commit -m b # creates revision 1 as a child of 0
$ hg up 0
$ hg mv a x
$ hg commit -m x # creates revision 2 as a child of 0
$ hg graft 1 # grafts revision 1 onto revision 2, creating revision 3
$ hg mv b y
$ hg commit -m y # creates revision 4 as a child of 3
$ hg up 1
$ echo bb > b
$ hg commit -m bb # creates revision 5 as a child of 1
$ hg up 4
$ hg graft 4 # should graft revision 5 onto 4, but fails
The final graft fails to identify the file named "y" as the equivalent of "b",
despite the rename information clearly identifying it as such, because it was
initially created by a graft, and therefore has no common ancestor in the DAG
with "b" in the source branch.
The obvious fix is to modify the _related function in copies.py to check graft
relationships in the absence of true DAG ancestry. The difficulty is that graft
is only one way a commit can end up "copied" to a new branch (rebase and evolve
come to mind, all recording origin information differently).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
