On 10.10.11 00:33:17, Jonathan Callen wrote: > -----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:
Indeed, though unlike the documentation suggests a simple git fetch --targs will do the job without the necessity to first delete the old tag. Andreas _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team