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

From: Greg Hurrell <greg@hurrell.net>
Date: Jun 9, 2021, 07:38 UTC
Message-ID: <26dbf49f-4972-4960-9383-2b69a3e6043c@www.fastmail.com>
In-Reply-To: <xmqqpmwvnbaz.fsf@gitster.g>

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

Show 12 quoted lines

> 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