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
