Christian Halstrick <christian.halstrick@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html