KDE 4.7.2 (try#1) uploaded

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/08/2011 06:21 PM, Andreas Pakulat wrote:
> On 08.10.11 15:24:57, Nicolas Alvarez wrote:
>> Andreas Pakulat wrote:
>> 
>>> On 08.10.11 01:10:50, Nicolas Alvarez wrote:
>>>> Andras Mantia wrote:
>>>>> On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I just finished uploading KDE 4.7.2 tarballs. Unlike
>>>>>> previous tarballs, these have been consistently taken
>>>>>> from KDE/4.7 branch in git.
>>>>> 
>>>>> What does this mean, no 4.7.2 tag was created in git? I
>>>>> don't see anything like that with "git tag" in kdepim and
>>>>> would like to check if some bugfix made into 4.7.2 or not. 
>>>>> dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 
>>>>> 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs)
>>>> 
>>>> Tags are created *after* the tarballs. If packagers find
>>>> problems in a non-final tarball, Dirk can release a new one,
>>>> but tags are immutable, so they should be created only once
>>>> we're sure everything is okay.
>>> 
>>> Sorry thats wrong:
>>> 
>>> git tag -a 4.7.2 <edit source file> git commit -a -m "Blah" git
>>> tag -f -a 4.7.2
>>> 
>>> works just fine and you can push the result without needing
>>> the force-parameter as long as the commit the tag points to now
>>> is a successor of the one it pointed to before.
>> 
>> As far as I know, that's not the case for annotated tags. If a
>> tag points at a commit A, it can be updated to commit B if A is
>> an ancestor of B. But if the tag points at an annotated tag
>> object which in turn points at commit A, you can't update it at
>> all. There is nothing that can be a successor of the tag object.
> 
> Did you actually try it out? I've done this twice in the last 4
> weeks at work and did not run into any problems. And neither did I
> when I tried right now :)
> 
> Andreas
> 

That works very well *until the tag is pushed*.  Once the tag has been
pushed, if you try and push a changed tag, anyone that pulled the repo
with the old tag *will not see the tag change*.  This behavior is by
design, the following excerpt from git-tag(1) explains why:

   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.

[end excerpt]

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJOknWNAAoJELHSF2kinlg4ELAP/iypplNPfMrdsCODfFG/tlCn
ILk+VQPJPdeB4x3NyHKHOlsX04+K+h0Voj0IQjy51fUGurAylaJ/cX+IDv6eTpNy
Xb4JX3uYCBzkzZFUfxhMvmpQXjx2h3ZRWjyQnfkGZXGF4rm+60CFD91ChjVlb6Bq
uJc4SlfFq+Zf7CrJ1pYjV6X/8hSKXjxKic5bZqXSZNErXI/VLThrGaJucXgheQkG
PeGjxZWEw1o/Wkz1//4v+muevYnK43k1EAn5/AOUWE4mybQfSMZuXyJWZhezQnn2
dnqY0IszDW3bFGNRnIF90/3pDGZ5Uudy+nxOl4ydeJ/c6Z06izmNkD4EDQPzJcY7
vvzedi0qNOHEGhLsxGwYIj7az9bPP1iBI8lBYRohl2O4iHSUqa8o+wOHgArwyGGf
lyXIo24NSZC0InjlnCymP4e7LBkabO0VtkxXDzzSpIZTirblnj40rIVxeUZrSiO6
lSk+oHpXF0jx2TdbXqZZObe8bZOGnHdqerty4wInl4rbNATuC8Td5ZiXZrBRmw2M
u58HJ6nWqWkU4QC0Nh3zTmu8/J5O2NfpwERethDTVaA0u19gB10KbaJkjxEPzqws
KMAkOqnKgKiSuwOfuP1HEl9z0t8ZNqU3Re45JxBJHEpL158Xgq6v/dA5mkceel3D
YNOWtUF1hWzDqdrbbUps
=dN1r
-----END PGP SIGNATURE-----