Re: How to create tags outside of refs/tags?

Christian Halstrick [off-list ref] writes:

I am not sure whether what is discussed now is really solving my
problem best. Maybe I rephrase again the problem I have:
I just want to make sure that certain commits are not garbage
collected. And the artefacts I create to ensure that should not
pollute the namespace of developer-created tags/branches. Is creating
a tag and then hiding it again really the best solution for that?

Here is some background: there is a tool developed in our company which
helps teams to release their git-controlled products. The release tool
gets as input just a commit ID. Whenever the release tool has
succesfully done his work on a product it wants to make sure the this
commit will never be garbage collected. Even not if month's later the
product owner resets all their branches making the released commits
beeing unreachable. And since some projects may run a lot of attempts
until they finally released some stuff we don't to have our tags
namespace to be polluted with too many attempt-to-release tags.

How about taking advantage of the fact that you do not have to treat tag
namespace as a global thing?  For the "release tool" to "get a commit ID"
and do something useful, the "release tool" must be working on a git
repository, and hopefully that repository is something other than the ones
developers directly play with (by checking out random branches in its
working tree and compiling, etc.).

You can run "git tag" in that "release tool" repository, and if you do not
want to show that to others, never let developers fetch tags from there.

I would think that using a private namespace other than tags for your own
use (e.g. "git update-ref refs/anchor/release-20110222 $that_commit") may
be the best option that is easiest to understand, though.

Hi,

How about taking advantage of the fact that you do not have to treat tag
namespace as a global thing?  For the "release tool" to "get a commit ID"
and do something useful, the "release tool" must be working on a git
repository, and hopefully that repository is something other than the ones
developers directly play with (by checking out random branches in its
working tree and compiling, etc.).

These assumptions are all correct. The "release tool" works on his clone
of a central repo. The release tool may even modify the content (e.g. increasing
release numbers in project metadata files) and create new git commits.
In the end it wants to create tags/refs locally und push these tags back
so that in the central repo the commits are not gc'ed.

Something like:

cd <releaseRepo>
git fetch origin
git checkout <commitIdToRelease>
edit pom.xml; git add pom.xml
git commit -m "release ..."
git tag <releaseName>
git push origin 'refs/tags/<releaseName>:refs/releases/<releaseName>'

should do the job, or?

Christian Halstrick venit, vidit, dixit 22.02.2011 23:08:

Hi,

quoted

How about taking advantage of the fact that you do not have to treat tag
namespace as a global thing?  For the "release tool" to "get a commit ID"
and do something useful, the "release tool" must be working on a git
repository, and hopefully that repository is something other than the ones
developers directly play with (by checking out random branches in its
working tree and compiling, etc.).

These assumptions are all correct. The "release tool" works on his clone
of a central repo. The release tool may even modify the content (e.g. increasing
release numbers in project metadata files) and create new git commits.
In the end it wants to create tags/refs locally und push these tags back
so that in the central repo the commits are not gc'ed.

Something like:

cd <releaseRepo>
git fetch origin
git checkout <commitIdToRelease>
edit pom.xml; git add pom.xml
git commit -m "release ..."
git tag <releaseName>
git push origin 'refs/tags/<releaseName>:refs/releases/<releaseName>'

should do the job, or?

Yep. Also, if you do

git tag release/<releasename>

then a simple push refspec 'refs/tags/release/*:refs/releases/*' in your
config does the job. (Assuming you don't have any other tags in release/.)

Michael

thanks all of you for your fast help. My problem is now solved.

* Junio C Hamano [off-list ref] wrote:

Hi folks,

I would think that using a private namespace other than tags for your own
use (e.g. "git update-ref refs/anchor/release-20110222 $that_commit") may
be the best option that is easiest to understand, though.

I'm doing similar things with source crawlers in the OSS-QM
project: each time a new upstream version arrives, it gets
tag into a queue namespace, so I can pick them up an do my
usual qm works on them one by one.

git ls-remote git://pubgit.metux.de/oss-qm/glib2.git | grep queue


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------