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

Gerardo Exequiel Pozzi vmlinuz386 at yahoo.com.ar
Thu May 30 11:43:32 EDT 2013

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)
>
> 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
>
>        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>