On Oct 21, 2011, at 21:51 , Adam Kocoloski wrote: > 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.
yes, agreed, it will make downstream life a lot easier and it doesn't cost us anything (aside from agreeing on it and writing it down) to follow this procedure. Cheers Jan --
