On Wed, Aug 14, 2019 at 2:14 PM Jason Merrill <ja...@redhat.com> wrote: > On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill <ja...@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
