On Oct 19, 2011, at 9:04 PM, Dustin Sallings wrote: > > 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
I think you might be reading a bit too much into what Noah is saying here. I believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names. For what it's worth I agree with him on that front, though I'd consider going even further (as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote. Then there's no need for any tag prefix at all. Best, Adam
