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) replaces v8 tagged by Gerardo Exequiel Pozzi on Thu May 30 12:12:10 2013 -0300
- Log ----------------------------------------------------------------- tagging
Gerardo Exequiel Pozzi (6): [archiso] patch not needed anymore [archiso] /usr/sbin -> /usr/bin [configs/releng] Add gpm and f2fs-tools [configs/releng] Use drop-in feature of systemd for getty autologin [configs/releng] Use a udev rule instead of dhcpcd.service prepare release
-----------------------------------------------------------------------
hooks/post-receive
On Thu, May 30, 2013 at 10:13 AM, Gerardo Exequiel Pozzi djgera@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.
On 05/30/2013 12:28 PM, Dan McGee wrote:
On Thu, May 30, 2013 at 10:13 AM, Gerardo Exequiel Pozzi djgera@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" toreplace the old one. And you're done.
But if you have pushed things out (or others could just readyour 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 adifferent 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 behindusers 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 changethe 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 waythat 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.
arch-releng@lists.archlinux.org