... Okay. Not sure what happened there. So, uh...
Can we do something like this:
It's the first round of voting, so we tag to:
vote/X.Y.X-1
This vote fails, so we move on to the second round of voting, and we tag to:
vote/X-Y.X-2
This vote passes, so we copy the tag to:
release/X.Y.Z
We then leave both the vote/* tags in place because they're prefixed to
avoid confusion.
On Fri, Oct 21, 2011 at 8:49 PM, Noah Slater <[email protected]> wrote:
> 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
>>
>>
>>
>>
>
