• Choose a category
• All
• Classic-Fiction

Colon (ASCII 58, :)

Carriage return (ASCII 13, \r)

Newline (ASCII 10, \n)

You can use the hg tags command to display the tags present in your repository. In the output, each tagged revision is identified first by its name, then by revision number, and finally by the unique hash of the revision.

$ hg tags

tip 1:ccd961c70ae0

v1.0 0:c78e12f9da76

Notice that tip is listed in the output of hg tags. The tip tag is a special “floating” tag, which always identifies the newest revision in the repository.

In the output of the hg tags command, tags are listed in reverse order by revision number. This usually means that recent tags are listed before older tags. It also means that tip is always going to be the first tag listed in the output of hg tags.

When you run hg log, if it displays a revision that has tags associated with it, it will print those tags.

$ hg log

changeset: 1:ccd961c70ae0

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:45 2009 +0000

summary: Added tag v1.0 for changeset c78e12f9da76

changeset: 0:c78e12f9da76

tag: v1.0

user: Bryan O'Sullivan

date: Tue May 05 06:44:45 2009 +0000

summary: Initial commit

Any time you need to provide a revision ID to a Mercurial command, the command will accept a tag name in its place. Internally, Mercurial will translate your tag name into the corresponding revision ID, then use that.

$ echo goodbye > myfile2

$ hg commit -A -m 'Second commit'

adding myfile2

$ hg log -r v1.0

changeset: 0:c78e12f9da76

tag: v1.0

user: Bryan O'Sullivan

date: Tue May 05 06:44:45 2009 +0000

summary: Initial commit

There’s no limit on the number of tags you can have in a repository, or on the number of tags that a single revision can have. As a practical matter, it’s not a great idea to have “too many” (a number that will vary from project to project), simply because tags are supposed to help you to find revisions. If you have lots of tags, the ease of using them to identify revisions diminishes rapidly.

For example, if your project has milestones as frequent as every few days, it’s perfectly reasonable to tag each one of those. But if you have a continuous build system that makes sure every revision can be built cleanly, you’d be introducing a lot of noise if you were to tag every clean build. Instead, you could tag failed builds (on the assumption that they’re rare!), or simply not use tags to track buildability.

If you want to remove a tag that you no longer want, use hg tag --remove.

$ hg tag --remove v1.0

$ hg tags

tip 3:6a30b02be96a

You can also modify a tag at any time, so that it identifies a different revision, by simply issuing a new hg tag command. You’ll have to use the -f option to tell Mercurial that you really want to update the tag.

$ hg tag -r 1 v1.1

$ hg tags

tip 4:2f612e0b083a

v1.1 1:ccd961c70ae0

$ hg tag -r 2 v1.1

abort: tag 'v1.1' already exists (use -f to force)

$ hg tag -f -r 2 v1.1

$ hg tags

tip 5:dd9e7a899c13

v1.1 2:9ac23a7cc526

There will still be a permanent record of the previous identity of the tag, but Mercurial will no longer use it. There’s thus no penalty to tagging the wrong revision; all you have to do is turn around and tag the correct revision once you discover your error.

Mercurial stores tags in a normal revision-controlled file in your repository. If you’ve created any tags, you’ll find them in a file in the root of your repository named .hgtags. When you run the hg tag command, Mercurial modifies this file, then automatically commits the change to it. This means that every time you run hg tag, you’ll see a corresponding changeset in the output of hg log.

$ hg tip

changeset: 5:dd9e7a899c13

tag: tip

user: Bryan O'Sullivan

date: Tue May 05 06:44:45 2009 +0000

summary: Added tag v1.1 for changeset 9ac23a7cc526

Handling Tag Conflicts During a Merge

You won’t often need to care about the .hgtags file, but it sometimes makes its presence known during a merge. The format of the file