Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

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