[timer] conflict between tools/inspect and libs/timer

Peter A. Bigot

26 Dec 2013 26 Dec '13

3:20 p.m.

A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail. The following process could help detect inter-module dependencies like this: * Initiate your workspace with the superproject checked out on branch master and all modules on the resulting commit (ignore branches). * Checkout the develop branch only for the module(s) you're working on. * Use "git submodule summary" at the superproject level to determine how your workspace differs from what would be expected in the master branch. If multiple modules show changes, there's a risk of coupling, and it might not be appropriate to push any of them to their master branch. * Use "git submodule update" to reset things when switching development between modules. Peter

Show replies by date

Peter A. Bigot

26 Dec 26 Dec

9:17 p.m.

On 12/26/2013 09:20 AM, Peter A. Bigot wrote:

...

A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail.

FWIW, b2 in libs/timer/test master works when tools/inspect and libs/filesystem are both on their develop branch. If only tools/inspect is on develop, inspect segfaults in boost::filesystem::initial_path() during static initialization. Perhaps it would be better not to update the superproject submodules automatically when a module pushes to master, and instead wait until integration testing infrastructure is in place. At least until the git module maintenance process is a bit more stable. Peter

Beman Dawes

11:07 p.m.

On Thu, Dec 26, 2013 at 4:17 PM, Peter A. Bigot wrote:

...

On 12/26/2013 09:20 AM, Peter A. Bigot wrote:

...
A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail.

FWIW, b2 in libs/timer/test master works when tools/inspect and libs/filesystem are both on their develop branch. If only tools/inspect is on develop, inspect segfaults in boost::filesystem::initial_path() during static initialization.

I haven't been able to reproduce that on Windows. What OS are you testing on? Once tools/inspect was merged and fixed, inspect worked fine.

...

Perhaps it would be better not to update the superproject submodules automatically when a module pushes to master, and instead wait until integration testing infrastructure is in place. At least until the git module maintenance process is a bit more stable.

There are pros and cons. Have patience for a few more days. --Beman

Peter A. Bigot

11:16 p.m.

On 12/26/2013 05:07 PM, Beman Dawes wrote:

...

On Thu, Dec 26, 2013 at 4:17 PM, Peter A. Bigot wrote:

...
...
A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail. FWIW, b2 in libs/timer/test master works when tools/inspect and

On 12/26/2013 09:20 AM, Peter A. Bigot wrote: libs/filesystem are both on their develop branch. If only tools/inspect is on develop, inspect segfaults in boost::filesystem::initial_path() during static initialization.

I haven't been able to reproduce that on Windows. What OS are you testing on?

Linux. Here's what I get: llc[53]$ ../../../bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect /opt/boost/libs/timer -text -brief Segmentation fault (core dumped) llc[54]$ printenv | grep LOCAL XTERM_LOCALE=en_US.UTF-8 llc[55]$ unset XTERM_LOCALE llc[56]$ printenv | grep LOCAL llc[57]$ ../../../bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect /opt/boost/libs/timer -text -brief Segmentation fault (core dumped) llc[58]$ gdb ../../../bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/... Reading symbols from /opt/boost/bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect...(no debugging symbols found)...done. (gdb) run /opt/boost/libs/timer -text -brief Starting program: /opt/boost/bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect /opt/boost/libs/timer -text -brief Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b3e495 in std::locale::locale(std::locale const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (gdb) where #0 0x00007ffff7b3e495 in std::locale::locale(std::locale const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x000000000045257c in boost::filesystem::path::codecvt() () #2 0x000000000044b3c8 in boost::filesystem::detail::current_path(boost::system::error_code*) () #3 0x000000000044b7a3 in boost::filesystem::detail::initial_path(boost::system::error_code*) () #4 0x0000000000407b62 in _GLOBAL__sub_I_boost_no_inspect () #5 0x000000000045486d in __libc_csu_init () #6 0x00007ffff7525700 in __libc_start_main (main=0x4050e0 <main>, argc=4, ubp_av=0x7fffffffde68, init=0x454810 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde58) at libc-start.c:185 #7 0x000000000040822d in _start () (gdb)

...

Once tools/inspect was merged and fixed, inspect worked fine.

The above was after just pulling and updating the submodules. After again checking out develop in libs/filesystem and re-invoking b2 it works: llc[60]$ ../../../bin.v2/tools/inspect/build/gcc-4.6/release/link-static/inspect /opt/boost/libs/timer -text -brief Boost Inspection Report Run Date: 23:15:28 UTC, Thursday 26 December 2013 Totals: 27 files scanned 14 directories scanned (including root) 21 problems reported [other output elided] So on Linux at least there seems to be another dependency. Peter

Beman Dawes

28 Dec 28 Dec

12:34 p.m.

On Thu, Dec 26, 2013 at 6:16 PM, Peter A. Bigot wrote:

...

On 12/26/2013 05:07 PM, Beman Dawes wrote:

...
On Thu, Dec 26, 2013 at 4:17 PM, Peter A. Bigot wrote:

On 12/26/2013 09:20 AM, Peter A. Bigot wrote:

...
...
A recent merge to master libs/timer includes support for inspect in the test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail.

FWIW, b2 in libs/timer/test master works when tools/inspect and libs/filesystem are both on their develop branch. If only tools/inspect is on develop, inspect segfaults in boost::filesystem::initial_path() during static initialization.

I haven't been able to reproduce that on Windows. What OS are you

testing on?

Linux. Here's what I get:

Reproduced on Linux. Critical changes on develop dating from February were never merged to trunk, and I set the git merge point I missed them. It may take a few days to figure out the best way to fix that. Thanks, --Beman

Peter Dimov

1:50 p.m.

Beman Dawes wrote:

...

Critical changes on develop dating from February were never merged to trunk, and I set the git merge point I missed them.

To avoid such (and other) surprises, what I did was ensure that develop and master are identical before doing the first merge. git diff --name-status master..develop gave me an overview on where the two branches differ; the same command without --name-status goes into more detail. (In principle, we all have kept our trunk and release branches in sync, so the above ought to have yielded nothing. In practice, however, all libraries likely had differences because (1) we sometimes forget to merge, (2) sometimes other people changed trunk and didn't merge and we didn't know, and (3) Stephen Kelly's Boost-wide changes were only on trunk.) I then proceeded to identify the commits causing each change. I don't remember how exactly I did that, probably by using git log on the modified files and by looking at the commit history on Github. After that, I applied each missing commit using git cherry-pick <sha>. That is, if a commit on develop was not present on master, I applied it to master with git cherry-pick; and if a commit on master was missing on develop (things like that do happen occasionally), I applied it on develop. I tried to do this in chronological order, which minimizes conflicts. What made it more interesting for me is that I sometimes didn't want a commit to be part of the initial state, so I reverted it using git revert instead of applying it to the other branch using git cherry-pick; but this should probably not be needed most of the time. The final result of all that cherry picking should be a state in which git diff master..develop doesn't report any differences. Once there, things are a simple "git merge" away. It's probably too late now for all that explanation, but I already wrote it. :-)

...

It may take a few days to figure out the best way to fix that.

The first thing I would try is git cherry-pick the missing commits into master.

Beman Dawes

2:46 p.m.

On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov wrote:

...

Beman Dawes wrote:

...
Critical changes on develop dating from February were never merged to trunk, and I set the git merge point I missed them.

It turned out the changes were merged into branches/release at the time, and setting the merge point backed them out! It was probably operator error on my part. If I had followed the procedure you suggest below, I would have caught the problem, and done so at a time when it was (1) easy to fix, and (2) the command history was still available so I could have figured out what I did wrong.

...

To avoid such (and other) surprises, what I did was ensure that develop and master are identical before doing the first merge.

git diff --name-status master..develop

gave me an overview on where the two branches differ; the same command without --name-status goes into more detail.

(In principle, we all have kept our trunk and release branches in sync, so the above ought to have yielded nothing. In practice, however, all libraries likely had differences because (1) we sometimes forget to merge, (2) sometimes other people changed trunk and didn't merge and we didn't know, and (3) Stephen Kelly's Boost-wide changes were only on trunk.)

I then proceeded to identify the commits causing each change. I don't remember how exactly I did that, probably by using git log on the modified files and by looking at the commit history on Github.

After that, I applied each missing commit using git cherry-pick <sha>. That is, if a commit on develop was not present on master, I applied it to master with git cherry-pick; and if a commit on master was missing on develop (things like that do happen occasionally), I applied it on develop. I tried to do this in chronological order, which minimizes conflicts.

What made it more interesting for me is that I sometimes didn't want a commit to be part of the initial state, so I reverted it using git revert instead of applying it to the other branch using git cherry-pick; but this should probably not be needed most of the time.

The final result of all that cherry picking should be a state in which git diff master..develop doesn't report any differences. Once there, things are a simple "git merge" away.

It's probably too late now for all that explanation, but I already wrote it. :-)

I'll add your explanation. I may also move the merge point instructions to their own page to make them stand out more.

...

It may take a few days to figure out the best way to fix that.

...
The first thing I would try is git cherry-pick the missing commits into master.

I ended up reverting the entire merge point commit, and then compared master and develop to verify. (I used TortoiseGit to revert the commit because I wasn't sure how to revert a commit from the command line leaving subsequent commits in place.) --Beman

Peter A. Bigot

4:41 p.m.

On 12/28/2013 08:46 AM, Beman Dawes wrote:

...

On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov wrote:

...
Beman Dawes wrote:

...
Critical changes on develop dating from February were never merged to trunk, and I set the git merge point I missed them.

It turned out the changes were merged into branches/release at the time, and setting the merge point backed them out! [...]

...
To avoid such (and other) surprises, what I did was ensure that develop and master are identical before doing the first merge.

git diff --name-status master..develop

gave me an overview on where the two branches differ; the same command without --name-status goes into more detail.

I'll add your explanation. I may also move the merge point instructions to their own page to make them stand out more.

Setting the merge point is the most critical, and most fragile, step. From playing with this in Boost.Test there are too many failure modes to anticipate, so careful review of the content at each step is very important. I have an annotated script showing the steps I performed in that case, which might be educational; I'll post it separately after I review it.

...

...
The first thing I would try is git cherry-pick the missing commits into master.

I ended up reverting the entire merge point commit, and then compared master and develop to verify.

(I used TortoiseGit to revert the commit because I wasn't sure how to revert a commit from the command line leaving subsequent commits in place.)

I highly recommend "git rebase -i" (interactive rebase) to do this sort of thing. Interactive rebase allows you to reorder (and remove) individual commits, squash together commits, and generally clean up the history of a branch so it's clean before you make it public. Peter

Cox, Michael

29 Dec 29 Dec

4:03 a.m.

On Sat, Dec 28, 2013 at 9:41 AM, Peter A. Bigot wrote:

...

On 12/28/2013 08:46 AM, Beman Dawes wrote:

...
On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov wrote:

Beman Dawes wrote:

...
Critical changes on develop dating from February were never merged to

...
trunk, and I set the git merge point I missed them.

It turned out the changes were merged into branches/release at the

time, and setting the merge point backed them out! [...]

To avoid such (and other) surprises, what I did was ensure that develop

...
and master are identical before doing the first merge.

git diff --name-status master..develop

gave me an overview on where the two branches differ; the same command without --name-status goes into more detail.

I'll add your explanation. I may also move the merge point instructions to their own page to make them stand out more.

Setting the merge point is the most critical, and most fragile, step. From playing with this in Boost.Test there are too many failure modes to anticipate, so careful review of the content at each step is very important. I have an annotated script showing the steps I performed in that case, which might be educational; I'll post it separately after I review it.

The first thing I would try is git cherry-pick the missing commits into

...
...
master.

I ended up reverting the entire merge point commit, and then compared master and develop to verify.

(I used TortoiseGit to revert the commit because I wasn't sure how to revert a commit from the command line leaving subsequent commits in place.)

I highly recommend "git rebase -i" (interactive rebase) to do this sort of thing. Interactive rebase allows you to reorder (and remove) individual commits, squash together commits, and generally clean up the history of a branch so it's clean before you make it public.

...

Peter

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Beman Dawes

26 Dec 26 Dec

11:09 p.m.

On Thu, Dec 26, 2013 at 10:20 AM, Peter A. Bigot wrote: A recent merge to master libs/timer includes support for inspect in the

...

test suite, but the invocation requires support for a search-root argument in inspect. That support is not present in tools/inspect's master branch, causing the libs/timer tests to fail.

The following process could help detect inter-module dependencies like this:

* Initiate your workspace with the superproject checked out on branch master and all modules on the resulting commit (ignore branches).

* Checkout the develop branch only for the module(s) you're working on.

* Use "git submodule summary" at the superproject level to determine how your workspace differs from what would be expected in the master branch. If multiple modules show changes, there's a risk of coupling, and it might not be appropriate to push any of them to their master branch.

* Use "git submodule update" to reset things when switching development between modules.

The real problem was that I blindly followed my own instructions, which failed to mention testing after the merge. I've now fixed that. See https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas... The tools/inspect problem should clear with the next super-project release. Thanks for the report! --Beman

Peter A. Bigot

27 Dec 27 Dec

12:24 a.m.

New subject: [git] tagging in modules

On 12/26/2013 05:09 PM, Beman Dawes wrote:

...

See

https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas... Not relevant to the original thread, but since I just noticed it: 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. I'd also really like to see any module that uses internal versioning also provide a mechanism by which code can determine which version is being used. E.g., for the above there ought to be a header which has: #define BOOST_TIMER_VERSION_MAJOR 1 #define BOOST_TIMER_VERSION_MINOR 2 Otherwise I'm not seeing any value for module-level version tags in the repository. Matter of taste, though. I would expect, on superproject release, that each module would continue to receive a boost-X.Y tag marking the module commit that corresponds to the submodule SHA1 used for the release. This is another reason to make sure module-level tags are clearly distinguished (lest somebody think the tag corresponds to a boost version rather than a module version). Peter

Cox, Michael

29 Dec 29 Dec

4:04 a.m.

New subject: [git] tagging in modules

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

...

On 12/26/2013 05:09 PM, Beman Dawes wrote:

...
See

https://svn.boost.org/trac/boost/wiki/StartModMaint# Lightweightlibraryrelease

Not relevant to the original thread, but since I just noticed it:

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

Good catch.

...

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.

I'd also really like to see any module that uses internal versioning also provide a mechanism by which code can determine which version is being used. E.g., for the above there ought to be a header which has:

#define BOOST_TIMER_VERSION_MAJOR 1 #define BOOST_TIMER_VERSION_MINOR 2

Otherwise I'm not seeing any value for module-level version tags in the repository.

...

Matter of taste, though.

I would expect, on superproject release, that each module would continue to receive a boost-X.Y tag marking the module commit that corresponds to the submodule SHA1 used for the release. This is another reason to make sure module-level tags are clearly distinguished (lest somebody think the tag corresponds to a boost version rather than a module version).

...

Peter

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Rene Rivera

4:10 a.m.

New subject: [git] tagging in modules

On Sat, Dec 28, 2013 at 10:04 PM, Cox, Michael wrote:

...

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

...
On 12/26/2013 05:09 PM, Beman Dawes wrote:

...

...
I'd also really like to see any module that uses internal versioning also provide a mechanism by which code can determine which version is being used. E.g., for the above there ought to be a header which has:

#define BOOST_TIMER_VERSION_MAJOR 1 #define BOOST_TIMER_VERSION_MINOR 2

Otherwise I'm not seeing any value for module-level version tags in the repository.

+1

Please use Boost.Predef for that. It's one of the main goals of the library. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Beman Dawes

30 Dec 30 Dec

5:02 p.m.

New subject: [git] tagging in modules

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

...

On 12/26/2013 05:09 PM, Beman Dawes wrote:

...
See

https://svn.boost.org/trac/boost/wiki/StartModMaint# Lightweightlibraryrelease

Not relevant to the original thread, but since I just noticed it:

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 https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas... https://svn.boost.org/trac/boost/wiki/StartModMaint #Lightweightlibraryreleasehttps://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas...

...

I'd also really like to see any module that uses internal versioning also provide a mechanism by which code can determine which version is being used. E.g., for the above there ought to be a header which has:

#define BOOST_TIMER_VERSION_MAJOR 1 #define BOOST_TIMER_VERSION_MINOR 2

Otherwise I'm not seeing any value for module-level version tags in the repository. Matter of taste, though.

While I'm sympathetic, we should get comments and buy in from library maintainers before recommending this. Are a lot of libraries already doing something similar? If so, what? And do we follow Rene's suggestion and recommend Predef? Could you please start a separate discussion with a subject that let's maintainers know this is affects them? Thanks! There is a tangentially related issue: The git and modular boost related docs are being developed without any reference to or updating of existing developer documentation. We need to get that underway. Ditto web site changes.

...

I would expect, on superproject release, that each module would continue to receive a boost-X.Y tag marking the module commit that corresponds to the submodule SHA1 used for the release. This is another reason to make sure module-level tags are clearly distinguished (lest somebody think the tag corresponds to a boost version rather than a module version).

Sounds about right, but we would need to work out the mechanics. Who does the tagging? A script release managers run? Thanks for the corrections and suggestions! --Beman

Ahmed Charles

4 Jan 4 Jan

11:38 a.m.

New subject: [git] tagging in modules

...

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:

...
On 12/26/2013 05:09 PM, Beman Dawes wrote:

...
See

https://svn.boost.org/trac/boost/wiki/StartModMaint# Lightweightlibraryrelease

Not relevant to the original thread, but since I just noticed it:

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 https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas... https://svn.boost.org/trac/boost/wiki/StartModMaint #Lightweightlibraryreleasehttps://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryreleas...

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.

Peter A. Bigot

12:59 p.m.

New subject: [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

Cox, Michael

6 Jan 6 Jan

8:44 a.m.

New subject: [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

4061

Age (days ago)

4072

Last active (days ago)

List overview

Download

16 comments

6 participants

participants (6)

Ahmed Charles
Beman Dawes
Cox, Michael
Peter A. Bigot
Peter Dimov
Rene Rivera