messed up dates and HASHID-only use make things extremely hard to find "in time order"

Mark Millard marklmi at
Fri Apr 23 23:48:41 UTC 2021

Using an example to illustrate problems finding artifacts,
the problems not being limited to the example's specifics.

I have historically used
to do build-less approximate bisecting (and other things). Such
use is very messed up since the git-related URL conventions
chosen were put in place. The below illustrates an example
of the mess for how things are currently presented.

lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having
date/time 2021-Apr-10 18:43 .


powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50
yet lists...
i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 .

But it gets worse:

shows an empty directory. Same for:

By contrast,

shows i386/ with date/time 2021-Apr-10 18:43 but

shows all the file dates as 2021-Feb-19 19:00 .

Going back to arm64/ I find a similar 2021-Feb-19 dating,
although 21021-Feb does show up in more places:

shows aarch64/ with date/time 2021-Feb-19 18:50 and

shows the files also having the date/time 2021-Feb-19 18:50 .

In my view the choice to only use the hash-id for the commit
in the url is a usability mistake and the url prefix should
be of a form more like (for this example context):

where the ?????? is from:

git rev-list --first-parent --count

(as used elsewhere by FreeBSD).

(The HASHID might be just the 12 character prefix instead of the
whole hash-id as well.)

Such a convention would be more independent of dates possibly
being touched on the file server and would make time ordered
finding of things (such as for build-less approximate bisecting)
far more reasonable.

Mark Millard
marklmi at
( went
away in early 2018-Mar)

More information about the freebsd-current mailing list