"Greg Hurrell" <email@example.com> writes: > 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.