* Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference [not found] ` <decec960-ce87-4704-6500-d17d23869590@mentor.com> @ 2019-06-11 15:13 ` Thomas Schwinge 2019-06-11 15:19 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Thomas Schwinge @ 2019-06-11 15:13 UTC (permalink / raw) To: gcc, Jakub Jelinek; +Cc: Kwok Cheung Yeung, Catherine_Moore 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:13 ` Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference Thomas Schwinge @ 2019-06-11 15:19 ` Jonathan Wakely 2019-06-11 15:26 ` Jonathan Wakely 2019-06-11 15:29 ` Thomas Schwinge 0 siblings, 2 replies; 11+ messages in thread From: Jonathan Wakely @ 2019-06-11 15:19 UTC (permalink / raw) To: Thomas Schwinge; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:19 ` Jonathan Wakely @ 2019-06-11 15:26 ` Jonathan Wakely 2019-06-11 15:29 ` Thomas Schwinge 1 sibling, 0 replies; 11+ messages in thread From: Jonathan Wakely @ 2019-06-11 15:26 UTC (permalink / raw) To: Thomas Schwinge; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:19 ` Jonathan Wakely 2019-06-11 15:26 ` Jonathan Wakely @ 2019-06-11 15:29 ` Thomas Schwinge 2019-06-11 15:33 ` Jonathan Wakely 1 sibling, 1 reply; 11+ messages in thread From: Thomas Schwinge @ 2019-06-11 15:29 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:29 ` Thomas Schwinge @ 2019-06-11 15:33 ` Jonathan Wakely 2019-06-11 15:35 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2019-06-11 15:33 UTC (permalink / raw) To: Thomas Schwinge; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:33 ` Jonathan Wakely @ 2019-06-11 15:35 ` Jonathan Wakely 2019-06-12 8:24 ` Thomas Schwinge 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2019-06-11 15:35 UTC (permalink / raw) To: Thomas Schwinge; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-11 15:35 ` Jonathan Wakely @ 2019-06-12 8:24 ` Thomas Schwinge 2019-06-20 12:06 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Thomas Schwinge @ 2019-06-12 8:24 UTC (permalink / raw) To: Jonathan Wakely, gcc; +Cc: Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-12 8:24 ` Thomas Schwinge @ 2019-06-20 12:06 ` Jonathan Wakely 2019-06-20 12:25 ` Vladislav Ivanishin 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2019-06-20 12:06 UTC (permalink / raw) To: Thomas Schwinge; +Cc: gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-20 12:06 ` Jonathan Wakely @ 2019-06-20 12:25 ` Vladislav Ivanishin 2019-06-20 12:45 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Vladislav Ivanishin @ 2019-06-20 12:25 UTC (permalink / raw) To: Jonathan Wakely Cc: Thomas Schwinge, gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-20 12:25 ` Vladislav Ivanishin @ 2019-06-20 12:45 ` Jonathan Wakely 2019-06-20 14:12 ` Andreas Schwab 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2019-06-20 12:45 UTC (permalink / raw) To: Vladislav Ivanishin Cc: Thomas Schwinge, gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference 2019-06-20 12:45 ` Jonathan Wakely @ 2019-06-20 14:12 ` Andreas Schwab 0 siblings, 0 replies; 11+ messages in thread From: Andreas Schwab @ 2019-06-20 14:12 UTC (permalink / raw) To: Jonathan Wakely Cc: Vladislav Ivanishin, Thomas Schwinge, gcc, Jakub Jelinek, Kwok Cheung Yeung, Moore, Catherine 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." ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-06-20 14:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <yxfpv9yjd7a9.fsf@hertz.schwinge.homeip.net>
[not found] ` <433a747bb9614c99bc1a6046f6567e74@SVR-ORW-MBX-04.mgc.mentorg.com>
[not found] ` <4e96f5c6-f157-5f95-076d-d21d33effbd9@ornl.gov>
[not found] ` <2ce74b08c05d471e8bb846389100d750@SVR-ORW-MBX-04.mgc.mentorg.com>
[not found] ` <yxfpmuit4dwa.fsf@hertz.schwinge.homeip.net>
[not found] ` <decec960-ce87-4704-6500-d17d23869590@mentor.com>
2019-06-11 15:13 ` Git 'gcc-9_1_0-release' tag vs. GCC 9.1 release: 'BASE-VER' difference Thomas Schwinge
2019-06-11 15:19 ` Jonathan Wakely
2019-06-11 15:26 ` Jonathan Wakely
2019-06-11 15:29 ` Thomas Schwinge
2019-06-11 15:33 ` Jonathan Wakely
2019-06-11 15:35 ` Jonathan Wakely
2019-06-12 8:24 ` Thomas Schwinge
2019-06-20 12:06 ` Jonathan Wakely
2019-06-20 12:25 ` Vladislav Ivanishin
2019-06-20 12:45 ` Jonathan Wakely
2019-06-20 14:12 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).