Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()
To
Greg Hurrell
Cc
git@vger.kernel.org
From
Junio C Hamano
See Also
Prev Ref 1
Date
2021-06-09 07:47:36 UTC
"Greg Hurrell" <greg@hurrell.net> 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.
>
>> 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.