This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Martin Liška <mliska at suse dot cz>, Richard Biener <richard dot guenther at gmail dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Paolo Bonzini <pbonzini at redhat dot com>
- Date: Thu, 19 Sep 2019 15:29:27 -0400
- Subject: Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)
- References: <CADzB+2=B=Fv34nqt+D103YCQocBTsVs80CCNFHkv_4cJ0gKfWQ@mail.gmail.com> <846D2EF4-879F-4518-ABA5-7DD74E6B4F18@linaro.org> <42281a3e-7a7a-d115-2468-b01275d00821@suse.cz> <D0620F01-2E44-4CE9-8600-0BB971C0D0CF@linaro.org> <a7d4d919-f353-97e5-e7f8-f922aa22dcea@suse.cz> <CAFiYyc2k3493HZ8zSM4zU5stzHzdnYDb5zqvLUDKE_pg7gu+vQ@mail.gmail.com> <ad4379d0-326d-a71b-75d3-af7d7782b7ff@suse.cz> <CADzB+2=f3mczjY06xCLO-VS3_b6EX02Kwz7YFKyAmtPBJe5AgQ@mail.gmail.com> <1e000037-44bd-7d5a-3817-d5048ecc4330@suse.cz> <CADzB+2=FM=5qDRqW-tzKOBp9yifi6N8QURE7JGWbMKWK7Cc3Sg@mail.gmail.com> <20190805153430.GT2726@tucnak> <3ea86e3a-4510-6279-64d6-d202fd77bb74@redhat.com> <CADzB+2mh7mvhPFPz1kOPEyNgqQuywxG7Z_E+dgKWDPnhsVu1XA@mail.gmail.com>
On Wed, Aug 14, 2019 at 2:14 PM Jason Merrill <jason@redhat.com> wrote:
> On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill <jason@redhat.com> wrote:
> > On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> > >> I agree. But for those who want a monotonically increasing
> > >> identifier, there's already one in git: CommitDate. In the discussion
> > >> of this issue four years ago,
> > >
> > > While commit date is monotonically increasing, it has the problem that at
> > > certain dates there are very few commits, at others many. When doing
> > > bisection by hand, one does the revision computation (min+max)/2 in head
> > > (it doesn't have to be precise of course, just roughly, and isn't perfect
> > > either, because in svn all of trunk and branches contribute to the revision
> > > numbers), with dates it would be division into further uneven chunks.
> >
> > That's true, but is it a major problem? If you have multiple commits on
> > one day, you (can) have multiple binaries with the same date and
> > different times, and you can adjust your heuristic for choosing the next
> > bisection point accordingly. Over longer periods, the number of commits
> > per day averages out.
> >
> > > Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> > > branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> > > trunk since the branchpoint, and let bugzilla and web redirection handle
> > > those rNN-NNNN style identifiers?
> > > git describe --all --match 'r[0-9]*' ... | sed ...
> > > to map hashes etc. to these rNN-NNNN identifiers and something to map them
> > > back to hashes say for git web?
> >
> > Well, having such tags would allow git describe to produce identifiers
> > that you might find more readable. For instance, if I do
> >
> > git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch)
>
> Though I guess what you were suggesting is slightly different: this
> will put the tag in the history of both trunk and branch, and it would
> be better for "r11" to be only in the history of GCC 11. So probably
> best to tag the commit that bumps BASE-VER instead, i.e.
>
> $ git tag -a -m 'GCC 10 stage 1 open' gcc10
> 70f448fa5347ba24e0916201dd8549bc16783ff0
> $ git tag -a -m 'GCC 9 stage 1 open' gcc9
> 949bc65ce4d0d7dd036ccfb279bffe63d02feee6
> $ git tag -a -m 'GCC 8 stage 1 open' gcc8
> 498621e8159c1f494a9b8a5f2c3e5225c74ed242
> ...
> $ git describe trunk
> gcc10-2527-gac18cc031cd
> $ git describe gcc-9-branch
> gcc9-7633-g28a024c36af
>
> Does this sound good to you? Anyone have thoughts about naming for the tags?
>
> Since alphabetical sorting won't do well with gcc9 and gcc10, you may
> want to use the beginning of time tag for naming your binaries. Also
> because the stage 1 boundary isn't that interesting for bisection.
>
> > git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe
> > git describe --match r1 trunk
> >
> > r1-170718-gdb868bacf6a
> >
> > These tags don't need to be shared, this works fine locally.
> >
> > Note that when you feed such an identifier to other git commands, they
> > ignore the first two parts and just use the hash.
> >
> > This might be a good alternative to dates for you, and people could
> > refer to them interchangeably with raw hashes in the web interface.
I suppose we also need to decide what form we want to use for the
equivalent of gcc.gnu.org/rNNNNN. I figure it needs to be some prefix
followed by a "commit-ish" (hash, tag, etc.). Perhaps "g:" as the
prefix, so
gcc.gnu.org/g:HEAD
gcc.gnu.org/g:gcc-9-branch
gcc.gnu.org/g:3cf0d8938a953e
?
Jason