Tags in Mercurial
Note: If you are migrating from ["CVS"], please [:CvsConcepts#tag:read this discussion of CVS tags] before you continue.
hg tag
hg tags
A tag is a symbolic identifier for a [:ChangeSet:changeset]. It can contain any characters except ":" (colon), "\r" (Carriage Return) or "\n" (Line Feed).
Mercurial has two kinds of tag.
A local tag is a convenience identifier that is not revision controlled, does not propagate with other changes, and lives in the .hg/localtags file in a [:Repository:repository].
A "regular" tag (with no special specifier) is revision controlled, does propagate with other changes, and lives in the .hgtags file in a repository. (It is therefore possible to remove tags by editing .hgtags and committing the change - this being the nearest equivalent to cvs tag -d).
How do tags work in Mercurial?
Tags work slightly differently in Mercurial than most revision systems. The design attempts to meet the following requirements:
be version controlled and [:Merge:mergeable] just like any other file
- allow signing of tags
allow adding a tag to an already [:Commit:committed] changeset
- allow changing tags in the future
Thus Mercurial stores tags as a file in the [:WorkingDirectory:working dir]. This file is called .hgtags and consists of a list of [:ChangeSetID:changeset IDs] and their corresponding tags. To add a tag to the system, simply add a line to this file and then commit it for it to take effect. The hg tag command will do this for you and hg tags will show the currently effective tags.
Note that because tags refer to changeset IDs and the changeset ID is effectively the sum of all the contents of the repository for that change, it is impossible in Mercurial to simultaneously commit and add a tag for the changeset being committed. Thus tagging a revision must be done as a second step. Thus, as above, the only changesets that can be tagged are ones already committed.
The fact that tags identify changesets and are also parts of changesets has some potentially confusing implications:
- The changeset that a tag refers to is always older than the changeset that commits the tag itself.
[:Update:Updating] a working dir to a particular tag will take that directory back to a point before the tag itself existed.
[:Clone:Cloning] a repo to a particular tag will give you a new repo that does not have that tag.
Common wisdom says that to avoid the confusion of a disappearing tag, you should clone the entire repo and then update the working directory to the tag. Thus preserving the tag in the repo.
What if I want to just keep local tags?
You can use "hg tag" command with an option -l or --local. This will store the tag in the file .hg/localtags, which will not be distributed or versioned. The format of this file is identical to the one of .hgtags and the tags stored there are handled the same.
How do tags work with multiple heads?
The tags that are in effect at any given time are the tags specified in each [:Head:head], with heads closer to the [:Tip:tip] taking precedence. Local tags override all other tags.
See also: [:MultipleHeads]
What if multiple lines with different revisions use the same tag name in .hgtags?
Only the last line where the tag appears is taken into account. The behavior is identical when this happens in .hg/localtags.