KDE 4.7.2 (try#1) uploaded

[Andreas Pakulat]

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