Thread (6 messages) 6 messages, 2 authors, 2021-06-08

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

From: Jeff King <hidden>
Date: 2021-06-08 08:34:26

On Sun, Jun 06, 2021 at 10:57:32AM +0200, Greg Hurrell wrote:
Prior to this commit, the "heads" section on a gitweb summary page would
list the heads in `-committerdate` order (ie. the most recently-modified
ones at the top).

In my own repos I have started to move from "master" towards "main", but
I keep "master" around and in sync with "main" so as not to break
existing clones. As such, they always point at the same commit.

This means that in the "heads" listing of a gitweb instance, the display
order ends up being determined by how `git for-each-ref` decides to
tie-break "master" and "main"
Hmm. I'd have expected it to, because we start the list in lexicographic
order. I suspect the sort we use simply isn't stable (in a simple 3-ref
example I made, "main" did sort before "master" by default). That would
be easy to fix, of course, but there may be value in using the HEAD rule
anyway.
For example, right now on a sample repo, gitweb shows the heads in this
order, even though "master" and "main" reference the same commit. The
tie-breaking evidently isn't happening lexicographically:

- master
- main
- pu
- next

So, this commit adds another `--sort` parameter to the `git
for-each-ref` invocation in `git_get_heads_list()`, ensuring that the
`HEAD` ref always ends up getting sorted to the top:

- main
- master
- pu
- next
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 don't have a strong feeling either way on that. It may surface an
older branch, but in general I'd expect the HEAD to be reasonably
up-to-date (unless somebody has a weird workflow that does not really
use it at all, and expects people to always clone with "-b" or
whatever. We can probably discount that).

It doesn't help the stability of non-HEAD branches that are in ties.
I.e., I wonder if this should be two separate patches:

  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

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help