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

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

On Tue, Jun 8, 2021, at 10:34 AM, Jeff King wrote:
> 
> In your earlier example, it sounded like you were primarily concerned
> with breaking ties. But here it sounds like you're proposing putting the
> HEAD first _regardless_ of the committer timestamp.

I arrived there organically. My initial goal was merely to find out why
"master" was sorting ahead of "main" even after I switched HEAD, as it
seemed arbitrary and possibly hard-coded.

Adding `--sort=-HEAD` wallpapers over the problem by forcing HEAD to the
top, but it doesn't address the underlying arbitrariness/non-determinism
of how refs with equal committerdate get treated.

So I like your idea of splitting this into two separate changes much
better:

>   1. break ties by name, like:
> 
>        git for-each-ref --sort=refname --sort=-committerdate
> 
>   2. emphasize the HEAD branch, even if it isn't the newest:
> 
>        git for-each-ref --sort=refname --sort=-committerdate --sort=-HEAD

I think adding "1" is a clear improvement. "2" is more debatable (I
think it would be of practical use, but as you said, HEAD is very often
going to be the most recently committed thing anyway). In my specific
use case (where "main" is the HEAD but "master" is kept in sync with it
automatically so as not to break existing clones), sorting by refname
_happens_ to mean that "main" will come before "master"; but that is of
course a quirk of my branch naming choices and not something that should
be relied upon.

In any case, splitting this into two pieces sounds good: we have the
option of taking one or both (or none).

Cheers,
Greg