[Bug 6146] New: Grafting .hgtags can lead to tag loss

[mercurial-bugs at mercurial-scm.org]

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

            Bug ID: 6146
           Summary: Grafting .hgtags can lead to tag loss
           Product: Mercurial
           Version: 4.8.1
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: bug
          Priority: normal
         Component: Mercurial
          Assignee: bugzilla at mercurial-scm.org
          Reporter: matt_harbison at yahoo.com
                CC: mercurial-devel at mercurial-scm.org

A repo at work has a few instances where a moficiation to .hgtags has been
grafted somewhere.  In one case where .hgtags had only a handful of entries,
.hgtags from another branch with a lot of entries was grafted over, and the
result was every new tag entry carried over, followed by a deletion line
("00..00 $tag").

It looks like what happened here is this repo was converted from bzr, and
already had several branches.  The convert extension put the .hgtags file on
default, and its descendant served as the graft source.  The destination branch
started from a head back in bzr, so it had .hgtags created from scratch.  We
have `:tagmerge` configured to handle .hgtags patterns.

The odd thing is that a merge in the same direction resulted in all of the tags
being carried over fine, without the deletions.  (I thought graft was just
merge, and then drop the p2 link.)  I'm not sure what the right behavior is
here- either bringing over only the tag changes in the source or everything
like a merge seems OK from a user perspective, but I'm not sure if that keeps
the code that cares about tag ranking happy.  Ignoring it (like rebase's commit
already an ancestor message) seems convenient for selecting a large range, but
maybe there is a use case if stripping the source branch later.

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