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: bugzi...@mercurial-scm.org
Reporter: dan...@gmail.com
CC: mercurial-devel@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.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
