Boost logo

Boost :

Subject: Re: [boost] [git] tagging in modules
From: Cox, Michael (mhcox_at_[hidden])
Date: 2014-01-06 03:44:55


On Sat, Jan 4, 2014 at 5:59 AM, Peter A. Bigot <pab_at_[hidden]> wrote:

> On 01/04/2014 05:38 AM, Ahmed Charles wrote:
>
>>
>> Date: Mon, 30 Dec 2013 12:02:58 -0500
>>> From: bdawes_at_[hidden]
>>> To: boost_at_[hidden]
>>> Subject: Re: [boost] [git] tagging in modules
>>>
>>> On Thu, Dec 26, 2013 at 7:24 PM, Peter A. Bigot <pab_at_[hidden]> 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.
>
>
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk