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)
git describe trunk
I get
b9-2260-gdb868bacf6a
i.e. commit #2260 since tag b9, with abbreviated hash gdb868bacf6a.
or if I do
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.
Jason
