[Bug 5343] New: Grafting a copy through a rename loses copy information

[bugzilla at mercurial-scm.org]

https://bz.mercurial-scm.org/show_bug.cgi?id=5343

            Bug ID: 5343
           Summary: Grafting a copy through a rename loses copy
                    information
           Product: Mercurial
           Version: 3.9
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: bug
          Priority: normal
         Component: Mercurial
          Assignee: bugzilla at selenic.com
          Reporter: gabor.stefanik at nng.com
                CC: mercurial-devel at selenic.com

Consider the following DAG:

1->2->3
 \
  -->4

Commit 1 contains a file, A, which is renamed to B in commit 2, and modified in
commit 2.

Commit 4, based on commit 1, copies A to C.

When commit 4 is grafted onto commit 3, C is added as a new file, with no copy
information (should be a copy of B instead). Contents will be the same as A in
revision 1, even though it makes more sense to me to have the contents of B in
revision 3 copied. A warning is shown about a missing ancestor.

If commit 4 is a move instead of a copy, we should be warning/prompting about a
divergent rename. Instead, the same thing happens as if it were a copy, only
this time no missing ancestor is reported.

If commit 4 is on top of commit 3 instead, and we try to graft it backwards to
commit 1, things are even worse: the copy is turned into an untracked move (the
original file is deleted for no reason, its contents dropped entirely), and if
there was a content change in-between, a conflict occurs. (This is related to
bug 4028; with my fix for that bug, backwards grafts behave like forward ones,
that is, they only show the basic version of this bug).

-- 
You are receiving this mail because:
You are on the CC list for the bug.