[arch-releng] [archiso] [GIT] The official archiso scripts repo annotated tag v9 updated. v9

[Gerardo Exequiel Pozzi]

On 05/30/2013 12:28 PM, Dan McGee wrote:
> On Thu, May 30, 2013 at 10:13 AM, Gerardo Exequiel Pozzi
> <djgera at archlinux.org> wrote:
>> This is an automated email from the git hooks/post-receive script. It was
>> generated because a ref change was pushed to the repository containing
>> the project "The official archiso scripts repo".
>>
>> The annotated tag, v9 has been updated
>>         to  5c7b0818492f70d22d9bfbaf80dfa2343d1bb718 (tag)
>>       from  1da4e795be63dac3f67ca01c7b86fe0cd140dbad (which is now obsolete)
>>    tagging  34c38fb78cdf89062a3aeadfb43e6ebafad23771 (commit)
> 
> FYI, it isn't usually a wise idea to update tags once they've been
> pushed. Anyone that has already pulled the original 'v9' tag will not
> get the new one because of a design decision made by git way back
> when.
> 
> -Dan
> 
>>From the manpage:
> 
> DISCUSSION
>    On Re-tagging
>        What should you do when you tag a wrong commit and you would
> want to re-tag?
> 
>        If you never pushed anything out, just re-tag it. Use "-f" to
> replace the old one. And you're done.
> 
>        But if you have pushed things out (or others could just read
> your repository directly), then others
>        will have already seen the old tag. In that case you can do one
> of two things:
> 
>         1. The sane thing. Just admit you screwed up, and use a
> different name. Others have already seen one
>            tag-name, and if you keep the same name, you may be in the
> situation that two people both have
>            "version X", but they actually have different "X"'s. So
> just call it "X.1" and be done with it.
> 
>         2. The insane thing. You really want to call the new version
> "X" too, even though others have already
>            seen the old one. So just use git tag -f again, as if you
> hadn't already published the old one.
> 
>        However, Git does not (and it should not) change tags behind
> users back. So if somebody already got the
>        old tag, doing a git pull on your tree shouldn't just make them
> overwrite the old one.
> 
>        If somebody got a release tag from you, you cannot just change
> the tag for them by updating your own
>        one. This is a big security issue, in that people MUST be able
> to trust their tag-names. If you really
>        want to do the insane thing, you need to just fess up to it,
> and tell people that you messed up. You
>        can do that by making a very public announcement saying:
> 
>            Ok, I messed up, and I pushed out an earlier version tagged as X. I
>            then fixed something, and retagged the *fixed* tree as X again.
> 
>            If you got the wrong tag, and want the new one, please delete
>            the old one and fetch the new one by doing:
> 
>                    git tag -d X
>                    git fetch origin tag X
> 
>            to get my updated tag.
> 
>            You can test which tag you have by doing
> 
>                    git rev-parse X
> 
>            which should return 0123456789abcdef.. if you have the new version.
> 
>            Sorry for the inconvenience.
> 
>        Does this seem a bit complicated? It should be. There is no way
> that it would be correct to just "fix"
>        it automatically. People need to know that their tags might
> have been changed.
> 

Yes, sorry the for mistake. But I retagged quickly, I guess nobody is
affected.

Thanks for the info.

-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-releng/attachments/20130530/2a3041af/attachment.asc>