[Bug 6462] New: Add support for lightweight, unversioned tags

[mercurial-bugs at mercurial-scm.org]

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

            Bug ID: 6462
           Summary: Add support for lightweight, unversioned tags
           Product: Mercurial
           Version: unspecified
          Hardware: All
               URL: https://foss.heptapod.net/mercurial/hg-git/-/merge_req
                    uests/73
                OS: All
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: Mercurial
          Assignee: bugzilla at mercurial-scm.org
          Reporter: danchr at gmail.com
                CC: mercurial-devel at mercurial-scm.org
    Python Version: ---

This is mostly a wish based on hg-git, but I figure it might be useful for
others as well. The current support in hg-git does not allow transferring tags
and other state, but I have a merge request[1] that implements some of that. I
thought I'd describe here what it would take to convert that into a generally
useful feature.

Lightweight tags are basically a reimplementation of Git's tags. They mostly
work well, but they have one issue: Once a tag is pushed, other users won't see
it unless they explicitly do a `git pull --prune-tags`. This is largely
necessary in order to make them trustworthy.

Since Mercurial already has trustworthy, versioned tags, I propose making
lightweight tags explicitly untrustworthy. When it comes to conflict
resolution; don't bother. The latest always wins. The hard part about these
tags is exchange, so I propose the following behaviour:

1) When pushing a changeset with a lightweight tag, always push the tag.
2) Always pull all tags, regardless of whether they exist locally. Remote wins.
3) If a tag is known both locally and remotely, only push it with an explicit
`-r`.
4) If a tag is known locally, but not remotely, always push it.

The first one is relatively simple to implement, as this only requires
embedding the tags in bundles; this is what I did for hg-git. The other three
require pushkey and are a bit more involved. The second one might be a bit
surprising if the user just created a tag, and wants to do a pull before a
push. I think a message describing what happened would address that, so at
least the user could reapply their change.

One way of thinking of these tags is that they are to regular tags what
bookmarks are to branches. If so, it might be advantageous to call them
something like “tagmarks” and give them similar push semantics this behaviour
is inconsistent with bookmarks. Personally, I'm inclined to consider the push
semantics of bookmarks more of a bug than a feature, so the inconsistency might
be worth it.

[1] https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/66

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