Re: [boost] [git] tagging in modules

On 01/04/2014 05:38 AM, Ahmed Charles wrote:

...

Date: Mon, 30 Dec 2013 12:02:58 -0500 From: bdawes@acm.org To: boost@lists.boost.org Subject: Re: [boost] [git] tagging in modules

On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot wrote:

...

git-push by default does not push tags: you need to specifically ask for the tag to be pushed (by name), or use --tags. So this sequence does nothing visible:

git tag -a 1.2 git push

Personally I'd prefer if tag symbols were a little more informative than "1.2", and followed a pattern that places them in a namespace reserved for the module, such as timer-1.2. Because tags aren't normally pushed, they're useful for individual developers to use as markers. However, git-pull will automatically retrieve tags attached to commits that are fetched unless --no-tags is given, so if a repository (from boostorg, or another developer) defines (or moves) a tag it might overwrite your local tag without warning. So it's important to know what tags you can expect might conflict with those in a remote repository to avoid conflicts.

Updated:

https://svn.boost.org/trac/boost/wiki/StartModWorkflow#Releasetags

Note: git doesn't overwrite local tags with remote ones, so once you push a tag, that tag should never be moved. There's discussion of this in the documentation.

+1 for making crystal clear that public tags should never be moved. +0.5 about overwrite. I confirm that by default local tags are not overwritten in git 1.8.4: I had remembered that happened to me, but it may be that I had foolishly added --tags to the fetch/pull command. With fetch/pull --tags the local tag will be overwritten. Although it also tells you it did so, there is no facility to figure out what the previous tag, um, tagged, so if the local association was considered important this is a non-recoverable loss. Conclusions: Do not use --tags on fetches unless you want to allow remote tags to overwrite your local tags. Never use --tags on pushes unless you want to add all your local tags to the remote. (This will not overwrite existing remote tags with the same names; you have to force that, at least as of git 1.8.4.) Best practice: When intending to push a single tag identify it by name only: git push boost-1.56 Peter