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

On Wed, Jun 9, 2021, at 2:15 AM, Junio C Hamano wrote:

Greg Hurrell <greg@hurrell.net <mailto:greg%40hurrell.net>> writes:

quoted

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