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

[Jason Merrill <jason at redhat dot com>]

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.

Jason

> 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.