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

["Greg Hurrell" <greg@hurrell.net>]

On Wed, Jun 9, 2021, at 2:15 AM, Junio C Hamano wrote:
> Greg Hurrell <greg@hurrell.net <mailto:greg%40hurrell.net>> writes:
> 
> > This seems to be a useful change, because I can't see anywhere else in
> > the gitweb UI where we actually indicate to the user what the "default"
> > branch is (ie. what they'll checkout if they run `git clone`).
> 
> The justification is a bit too weak to convince readers that using
> %(HEAD) as the primary sort key to list the branch first in the list
> view is *the* best way to solve the "it is unclear which one is the
> defaul branch" problem, though.  An obvious alternative would be to
> show '*' next to such a branch just like "git branch --list" does,
> without changing the sort order at all, for example.

Yeah, I'm not 100% convinced either. Displaying a "*" indicator
would be a straightforward change to `git_heads_body()`, but it would be
a break with the visual style of all the other tables in the UI.

On the other hand, boosting `HEAD` to the top like the proposed commit
does feel a bit arbitrary, given that the other list views in the UI
seem mostly to be sorted by recency. (But then again, what `HEAD` is
and what it means is quintessentially arbitrary, so maybe this _is_
appropriate.)

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.

Cheers,
Greg