On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge <tho...@codesourcery.com> wrote: > > > > Hi! > > > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely <jwakely....@gmail.com> > > wrote: > > > On Tue, 11 Jun 2019 at 16:13, Thomas Schwinge <tho...@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.
