Question

As the definite guide aptly points out (search for “Tags and cloning”):

When you run hg clone -r foo to clone a repository as of tag foo, the new
clone will not contain any revision newer than the one the tag refers to,
including the revision where the tag was created. The result is that you’ll
get exactly the right subset of the project’s history in the new
repository, but not the tag you might have expected.

It means hg tags in your new clone does NOT show the foo tag. Same thing happens if you had cloned before foo tag was added, and you do hg pull -r foo.

(Digression: tag is about the only thing I don’t quite get in hg. I understand there are advantages (e.g. merge) in putting it in a changeset, but it always feels weird to have meta data mixed with source code.)

It should be obvious that I’m asking for an automated way, instead of pulling the tag changeset as a separate manual step.

I know I could check for this scenario in an incoming hook (so it works for both clone and pull), or wrap clone and pull.

But is there a better/easier way?

---

UPDATE hg bug tracker already has this issue.

Answer 1

Yes it can be done by post-clone/pull hooks, but there are a couple of crooks.

First, it only works for local repo, since you can’t get the list of tags in a remote repo.

Second, dealing with clone/pull arguments and options is not trivial. (For clone I need to get the target repo, -r, -u, -U. For pull I need -r and -u.) I tried to use fancyopts, but it can’t deal with global options, which are processed away in dispatch. I managed to hack dispatch to give me only the args and opts of a command, but it feels and looks ugly.

Using command wrapper would eliminate the second problem.

I hope one day hg will add an option to clone and pull to do it cleanly.