On Fri, Oct 21, 2011 at 2:42 PM, Dustin Sallings <[email protected]> wrote: > > On Oct 21, 2011, at 11:25 AM, Robert Newson wrote: > >> /tmp/bar $ git pull --tags >> remote: Counting objects: 4, done. >> remote: Compressing objects: 100% (2/2), done. >> remote: Total 3 (delta 0), reused 0 (delta 0) >> Unpacking objects: 100% (3/3), done. >> From /tmp/foo >> - [tag update] 1.0 -> 1.0 >> Fetching tags only, you probably meant: >> git fetch --tags >> >> The 1.0 tag was correctly updated. > > > You aren't disagreeing with the thing I'm most concerned, but the > thing I'm second-to-most concerned about but directly brought up. > > I pointed out that you can't *remove* tags, since that's what's > required for a renaming strategy. Here you're just showing that if every > user everywhere who has a clone of the official repo issues a non-default > update command before looking at tags, then there's no problem. I think this > might be less reasonable than it sounds.
I think our wires were crossed a bit. The rename isn't really a rename directly. Once a release is made, we just copy the final vote tag to a new tag that is prefixed/suffixed/something to indicate "this is the tag that corresponds to what's in the dist directory." Removing tags would occur after a final vote passed and would only be a minor "maybe get rid of cruft to avoid confusion" step. > > For example: Let's say I'm doing an automated build for my OS > distribution from the 1.0 tag and have shipped stuff out to my customers. > How will you know that there was no failure in my two tiers of git repos that > caused my build to miss the update to your 1.0 tag between the time that you > issued the first one, announced the second one, I did an update from a mirror > during an upstream outage and see the 1.0 tag and ship it and then find a > bug? Which 1.0 did I ship? > Right, this is the current state of affairs we've been dealing with using SVN and what we're looking to fix. > -- > dustin sallings > > > >
