On Wed, 12 Jun 2019 at 09:24, Thomas Schwinge <tho...@codesourcery.com> wrote: > > Hi! > > On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely <jwakely....@gmail.com> > wrote: > > 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: > > > > 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 > > 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)
