[Bug 5834] New: If a grafted file is renamed, subsequent grafts fail to find it

[mercurial-bugs at mercurial-scm.org]

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: bugzilla at mercurial-scm.org
          Reporter: gabor.stefanik at nng.com
                CC: mercurial-devel at 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.