KDE 4.7.2 (try#1) uploaded

[Andreas Pakulat]

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