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

From: Greg Hurrell <greg@hurrell.net>
Date: Jun 8, 2021, 09:02 UTC
Message-ID: <f04ffea4-ff37-432a-a0c6-abe11721060b@www.fastmail.com>
In-Reply-To: <YL8rjeKQPOtQSyzT@coredump.intra.peff.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:

Show 7 quoted lines

>   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