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

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

[Thomas Schwinge]

Hi!

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) 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.)

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.


Grüße
 Thomas

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

[Jonathan Wakely]

On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> 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) 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?

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

[Jonathan Wakely]

On Tue, 11 Jun 2019 at 16:18, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge <thomas@codesourcery.com> wrote:
> >
> > Hi!
> >
> > 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) 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 I can do that by pushing a new tag to the repo, but
somebody with the right privs could do it locally on sourceware.org. I
think Jason and Joseph should be able to, maybe others too.

Changing a tag isn't like rebasing history of a branch, it's not going
to mess things up for anybody.

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

[Thomas Schwinge]

Hi!

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
different clones might then have different 'gcc-9_1_0-release' tags.


Grüße
 Thomas

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

[Jonathan Wakely]

On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> 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

I think that's right, but 'git fetch --tags' would update it.

> 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.

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

[Jonathan Wakely]

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:
> >
> > Hi!
> >
> > 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
>
> I think that's right, but 'git fetch --tags' would update it.
>
> > 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.

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

[Thomas Schwinge]

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?


Grüße
 Thomas

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

[Jonathan Wakely]

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.

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)

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

[Vladislav Ivanishin]

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).

-- 
Vlad

>
> 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)

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

[Jonathan Wakely]

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)

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

[Andreas Schwab]

On Jun 20 2019, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> 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.

You need to have a recent version of git to get that error.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."