Can we do something like this:
On Fri, Oct 21, 2011 at 8: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. > > 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? > > -- > dustin sallings > > > >
