Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 9, 2021, 07:47 UTC
- Message-ID
- <xmqqpmwviinb.fsf@gitster.g>
- In-Reply-To
- <26dbf49f-4972-4960-9383-2b69a3e6043c@www.fastmail.com>
"Greg Hurrell" <greg@hurrell.net> writes:
Show 26 quoted lines
> 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.
I agree that using HEADness as a tiebreaker is a much easier sell.
Another idea would be to give site administrators (or even to the end users via UI) an option to tweak how they are sorted.