Thread (2 messages) 2 messages, 2 authors, 2021-06-09

Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()

From: Junio C Hamano <hidden>
Date: 2021-06-09 07:47:44

Possibly related (same subject, not in this thread)

"Greg Hurrell" [off-list ref] writes:
One thing I do notice is that there is already a `current_head` CSS
class applied to the corresponding row, so it would be possible for the
gitweb owner to make tha row stand out however they pleased.

In short, I am happy to amend the commit message but I fear the
rationale for it is a bit weak. If nobody chimes in with a resounding
endorsement, I am inclined to probably drop it.
quoted
Wasn't your motivating example about tiebreaking between 'main' and
'master' that always point at the same commit?
Yes indeed, that was the original motivation, although after the fix
in 7c5045fc180ed09ed4cb5 the tie-breaking by refname already has the
equivalent desired effect, albeit coincidentally.

Perhaps the sort keys _should_ be `-committerdate`, then `-HEAD`, then
`refname` (implicit default); ie. `--sort=-HEAD --sort=-committerdate`
(which is the opposite order to what I have in the patch). I would have
prepared the patch in that way in the first place if my testing hadn't
been confounded by the fact that I was running an older version of Git
on the installation where I was trying it out.

I feel the argument for using `HEAD` as a tiebreaker is easier to make
than the case for using it as a primary sort key, because it is a less
invasive change. If there is support for that idea, I'll tweak the
patch.
I agree that using HEADness as a tiebreaker is a much easier sell.

Another idea would be to give site administrators (or even to the
end users via UI) an option to tweak how they are sorted.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help