On Oct 19, 2011, at 2:33 PM, Noah Slater wrote:
> Why not just have a top level tags/ directory that prevents rewriting. In
> that you'd tag a release candidate as X.Y.Z-rc1, X.Y.Z-rc2, etc until a vote
> passed, at which point, you copy the tag to X.Y.Z. I don't see a need
> to separate these out with a second level directory.
Probably best to not consider tags as svn refers to them. It's not a
copy, just a pointer to a commit that was the last one in the release (which,
in turn, points to the commits that preceded it).
In git, tags generally get a ref prefix of refs/tags/ (it's more of a
namespace than a directory). I'd recommend not doing anything different from
what git will give you out of the box. Tag your rc, tag it again when it
becomes a release.
Tags are intentionally hard to rid yourself of in git. Once you
publish a "this is 2.5", getting a second chance requires coordination. You
can overwrite them locally, of course, but once they're published and
replicated, the down streams basically have to agrees to move.
I'm a bit of a bystander, but I'd really want to see strong
justification for not wanting to use git's normal tools and methodologies.
--
dustin sallings
