On Oct 21, 2011, at 3:42 PM, Dustin Sallings 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. > > 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?
+1 We can argue that the only true '1.1.1' is the tarball you grab from the ASF mirrors, but realistically the type of scenario Dustin describes is pretty darn common.
