Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On Thu, 20 Jun 2019 at 13:25, Vladislav Ivanishin <vlad@ispras.ru> wrote:
>
> Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>
> > On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge <thomas@codesourcery.com> wrote:
> >>
> >> Hi!
> >>
> >> On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >> > On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >> > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge <thomas@codesourcery.com> wrote:
> >> > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >> > > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge <thomas@codesourcery.com> wrote:
> >> > > > > > We have found that the Git 'gcc-9_1_0-release' tag doesn't correspond to
> >> > > > > > the actual GCC 9.1 release.  The GCC 9.1 release (as per 'gcc-9.1.0.tar'
> >> > > > > > as well as 'svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_9_1_0_release',
> >> > > > > > r272156)
> >> > > >
> >> > > > (Eh, at the end of that 'svn co [...]', it printed that it "Checked out
> >> > > > revision 272156", but the GCC 9.1 release actually is r270840, and
> >> > > > r272156 is GCC trunk from a moment ago.)
> >> > > >
> >> > > > > > would correspond to Git commit
> >> > > > > > 3defceaa1a2987fa90296abfbcc85d7e9ad59684 "Update ChangeLog and version
> >> > > > > > files for release", but the Git 'gcc-9_1_0-release' tag points one commit
> >> > > > > > further: Git commit 1f54d412a517f3a4b82f3dd77517842fb4de099a "BASE-VER:
> >> > > > > > Set to 9.1.1".  (That's not a big problem; the 'BASE-VER' update is
> >> > > > > > indeed the only difference.)
> >> > > > >
> >> > > > > That's probably my fault, I think I created the tag.
> >> > > > >
> >> > > > > > The Git tag can't be corrected now (would it make sense to push a Git
> >> > > > > > 'gcc-9_1_0-release-corrected' tag?), but I wanted to post this, to get it
> >> > > > > > into the mighty Internet archives; may this note help others who stumble
> >> > > > > > over the same thing.
> >> > > > >
> >> > > > > Can't we just delete the tag and add it at the right commit?
> >> > > >
> >> > > > I don't think that'll be useful: as far as I remember (but please correct
> >> > > > me if I'm wrong!), a 'git fetch' will not re-fetch changed tags, so
> >>
> >> Right, see the "DISCUSSION" "On Re-tagging" in 'git tag --help'.
> >>
> >> > > I think that's right, but 'git fetch --tags' would update it.
> >>
> >> Sure, but who's running that?  ;-)
> >>
> >> (We shall see if the GitHub etc. mirrors will pick up the updated tag
> >> automatically.)
> >>
> >> > > > different clones might then have different 'gcc-9_1_0-release' tags.
> >> > >
> >> > > Which doesn't seem like a problem to me.
> >> > >
> >> > > I could create a local tag with that name for any arbitrary revision.
> >> > > It wouldn't match what's in everybody else's clone, but that's fine.
> >> >
> >> > It seems to me that having the master repo have the correct tag is
> >> > more valuable than everybody having the same tag.
> >> >
> >> > And because, as you say, the difference is just one commit, it's not
> >> > like doing diffs or other commands using the old value of the tag
> >> > would look at a completely wrong branch or completely different
> >> > histories.
> >>
> >> Note that I'm not objecting to re-tagging.  (I had just proposed
> >> 'gcc-9_1_0-release-corrected' to make obvious what's going on.)
> >>
> >> Is there sufficient consensus, or who's going to make a decision?
> >
> > After some more discussion on IRC, and with Jakub's approval, I fixed
> > the tag by running this on the server:
> >
> > git update-ref refs/tags/gcc-9_1_0-release
> > 3defceaa1a2987fa90296abfbcc85d7e9ad59684
> > 1f54d412a517f3a4b82f3dd77517842fb4de099a
> >
> > The same command can be run in a clone to update local tags.
>
> Or `git fetch --tags -f` (not particularly well documented in the git
> manual, but intuitive; worked for me).

Thanks, I meant to check if -f did it, and forgot to.

Other people have reported that their clones updated the tag without
any problems, so the "would clobber existing tag" error I got might be
because I've been creating and removing that tag locally. If you have
never done that, and just fetched from gcc.gnu.org, then it might
update smoothly without issues.

> >
> > Running 'git fetch --tags' will give an error if you already have that tag:
> >
> >  ! [rejected]                gcc-9_1_0-release -> gcc-9_1_0-release
> > (would clobber existing tag)