Re: [boost] [git] tagging in modules

On Sat, Jan 4, 2014 at 5:59 AM, Peter A. Bigot wrote:

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

...

...

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

Date: Mon, 30 Dec 2013 12:02:58 -0500 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.

Just to be precise, git fetch/pull --tags will overwrite local tags *with the same name*, i.e. tags that you have overwritten locally (which, again, you shouldn't be doing). So if you have your own set of local "lightweight" tags for your own purpose, e.g. tag last_time_I_ran_unit_tests, those won't be overwritten by a git pull/fetch --tags. At least with git 1.8.4.2.

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

... and any tag you push should probably be an "annotated" (with the git-tag -a option as shown above) vs. a "lightweight" tag. From the git-tag manual: Tag objects (created with -a, s, or -u) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object). Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default. Michael