{"thread":{"id":"55851","subject":"[RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","startedAt":"2021-06-06T08:51:27Z","lastAt":"2021-06-09T19:28:35Z","messageCount":10,"participants":["Greg Hurrell","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"426523","messageId":"20210606085116.13739-1-greg@hurrell.net","threadId":"55851","inReplyTo":null,"subject":"[RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-06T08:51:16Z","receivedAt":"2021-06-06T08:51:27Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"Prior to this commit, the \"heads\" section on a gitweb summary page would\nlist the heads in `-committerdate` order (ie. the most recently-modified\nones at the top).\n\nIn my own repos I have started to move from \"master\" towards \"main\", but\nI keep \"master\" around and in sync with \"main\" so as not to break\nexisting clones. As such, they always point at the same commit.\n\nThis means that in the \"heads\" listing of a gitweb instance, the display\norder ends up being determined by how `git for-each-ref` decides to\ntie-break \"master\" and \"main\"\n\nFor example, right now on a sample repo, gitweb shows the heads in this\norder, even though \"master\" and \"main\" reference the same commit. The\ntie-breaking evidently isn't happening lexicographically:\n\n- master\n- main\n- pu\n- next\n\nSo, this commit adds another `--sort` parameter to the `git\nfor-each-ref` invocation in `git_get_heads_list()`, ensuring that the\n`HEAD` ref always ends up getting sorted to the top:\n\n- main\n- master\n- pu\n- next\n\nThis seems to be a useful change, because I can't see anywhere else in\nthe gitweb UI where we actually indicate to the user what the \"default\"\nbranch is (ie. what they'll checkout if they run `git clone`).\n---\n gitweb/gitweb.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex e09e024a09..e5270b0291 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3796,7 +3796,8 @@ sub git_get_heads_list {\n \tmy @headslist;\n \n \topen my $fd, '-|', git_cmd(), 'for-each-ref',\n-\t\t($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',\n+\t\t($limit ? '--count='.($limit+1) : ()),\n+\t\t'--sort=-committerdate', '--sort=-HEAD',\n \t\t'--format=%(objectname) %(refname) %(subject)%00%(committer)',\n \t\t@patterns\n \t\tor return;\n-- \n2.29.2\n\n"},{"id":"426524","messageId":"20210606085732.15001-1-greg@hurrell.net","threadId":"55851","inReplyTo":"20210606085116.13739-1-greg@hurrell.net","subject":"[RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-06T08:57:32Z","receivedAt":"2021-06-06T08:57:47Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"Prior to this commit, the \"heads\" section on a gitweb summary page would\nlist the heads in `-committerdate` order (ie. the most recently-modified\nones at the top).\n\nIn my own repos I have started to move from \"master\" towards \"main\", but\nI keep \"master\" around and in sync with \"main\" so as not to break\nexisting clones. As such, they always point at the same commit.\n\nThis means that in the \"heads\" listing of a gitweb instance, the display\norder ends up being determined by how `git for-each-ref` decides to\ntie-break \"master\" and \"main\"\n\nFor example, right now on a sample repo, gitweb shows the heads in this\norder, even though \"master\" and \"main\" reference the same commit. The\ntie-breaking evidently isn't happening lexicographically:\n\n- master\n- main\n- pu\n- next\n\nSo, this commit adds another `--sort` parameter to the `git\nfor-each-ref` invocation in `git_get_heads_list()`, ensuring that the\n`HEAD` ref always ends up getting sorted to the top:\n\n- main\n- master\n- pu\n- next\n\nThis seems to be a useful change, because I can't see anywhere else in\nthe gitweb UI where we actually indicate to the user what the \"default\"\nbranch is (ie. what they'll checkout if they run `git clone`).\n\nSigned-off-by: Greg Hurrell <greg@hurrell.net>\n---\n\nResending because I forgot the Signed-off-by the first time. Sorry for\nthe noise.\n\n gitweb/gitweb.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex e09e024a09..e5270b0291 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3796,7 +3796,8 @@ sub git_get_heads_list {\n \tmy @headslist;\n \n \topen my $fd, '-|', git_cmd(), 'for-each-ref',\n-\t\t($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',\n+\t\t($limit ? '--count='.($limit+1) : ()),\n+\t\t'--sort=-committerdate', '--sort=-HEAD',\n \t\t'--format=%(objectname) %(refname) %(subject)%00%(committer)',\n \t\t@patterns\n \t\tor return;\n-- \n2.29.2\n\n"},{"id":"426733","messageId":"YL8rjeKQPOtQSyzT@coredump.intra.peff.net","threadId":"55851","inReplyTo":"20210606085732.15001-1-greg@hurrell.net","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-06-08T08:34:21Z","receivedAt":"2021-06-08T08:34:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 06, 2021 at 10:57:32AM +0200, Greg Hurrell wrote:\n\n> Prior to this commit, the \"heads\" section on a gitweb summary page would\n> list the heads in `-committerdate` order (ie. the most recently-modified\n> ones at the top).\n> \n> In my own repos I have started to move from \"master\" towards \"main\", but\n> I keep \"master\" around and in sync with \"main\" so as not to break\n> existing clones. As such, they always point at the same commit.\n> \n> This means that in the \"heads\" listing of a gitweb instance, the display\n> order ends up being determined by how `git for-each-ref` decides to\n> tie-break \"master\" and \"main\"\n\nHmm. I'd have expected it to, because we start the list in lexicographic\norder. I suspect the sort we use simply isn't stable (in a simple 3-ref\nexample I made, \"main\" did sort before \"master\" by default). That would\nbe easy to fix, of course, but there may be value in using the HEAD rule\nanyway.\n\n> For example, right now on a sample repo, gitweb shows the heads in this\n> order, even though \"master\" and \"main\" reference the same commit. The\n> tie-breaking evidently isn't happening lexicographically:\n> \n> - master\n> - main\n> - pu\n> - next\n> \n> So, this commit adds another `--sort` parameter to the `git\n> for-each-ref` invocation in `git_get_heads_list()`, ensuring that the\n> `HEAD` ref always ends up getting sorted to the top:\n> \n> - main\n> - master\n> - pu\n> - next\n\nIn your earlier example, it sounded like you were primarily concerned\nwith breaking ties. But here it sounds like you're proposing putting the\nHEAD first _regardless_ of the committer timestamp.\n\nI don't have a strong feeling either way on that. It may surface an\nolder branch, but in general I'd expect the HEAD to be reasonably\nup-to-date (unless somebody has a weird workflow that does not really\nuse it at all, and expects people to always clone with \"-b\" or\nwhatever. We can probably discount that).\n\nIt doesn't help the stability of non-HEAD branches that are in ties.\nI.e., I wonder if this should be two separate patches:\n\n  1. break ties by name, like:\n\n       git for-each-ref --sort=refname --sort=-committerdate\n\n  2. emphasize the HEAD branch, even if it isn't the newest:\n\n       git for-each-ref --sort=refname --sort=-committerdate --sort=-HEAD\n\n-Peff\n"},{"id":"426748","messageId":"f04ffea4-ff37-432a-a0c6-abe11721060b@www.fastmail.com","threadId":"55851","inReplyTo":"YL8rjeKQPOtQSyzT@coredump.intra.peff.net","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-08T09:02:15Z","receivedAt":"2021-06-08T09:02:40Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"On Tue, Jun 8, 2021, at 10:34 AM, Jeff King wrote:\n> \n> In your earlier example, it sounded like you were primarily concerned\n> with breaking ties. But here it sounds like you're proposing putting the\n> HEAD first _regardless_ of the committer timestamp.\n\nI arrived there organically. My initial goal was merely to find out why\n\"master\" was sorting ahead of \"main\" even after I switched HEAD, as it\nseemed arbitrary and possibly hard-coded.\n\nAdding `--sort=-HEAD` wallpapers over the problem by forcing HEAD to the\ntop, but it doesn't address the underlying arbitrariness/non-determinism\nof how refs with equal committerdate get treated.\n\nSo I like your idea of splitting this into two separate changes much\nbetter:\n\n>   1. break ties by name, like:\n> \n>        git for-each-ref --sort=refname --sort=-committerdate\n> \n>   2. emphasize the HEAD branch, even if it isn't the newest:\n> \n>        git for-each-ref --sort=refname --sort=-committerdate --sort=-HEAD\n\nI think adding \"1\" is a clear improvement. \"2\" is more debatable (I\nthink it would be of practical use, but as you said, HEAD is very often\ngoing to be the most recently committed thing anyway). In my specific\nuse case (where \"main\" is the HEAD but \"master\" is kept in sync with it\nautomatically so as not to break existing clones), sorting by refname\n_happens_ to mean that \"main\" will come before \"master\"; but that is of\ncourse a quirk of my branch naming choices and not something that should\nbe relied upon.\n\nIn any case, splitting this into two pieces sounds good: we have the\noption of taking one or both (or none).\n\nCheers,\nGreg\n"},{"id":"426814","messageId":"20210608211440.37985-1-greg@hurrell.net","threadId":"55851","inReplyTo":"f04ffea4-ff37-432a-a0c6-abe11721060b@www.fastmail.com","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-08T21:14:40Z","receivedAt":"2021-06-08T21:15:36Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"Prior to this commit, the \"heads\" section on a gitweb summary page would\nlist the heads in `-committerdate` order (ie. the most recently-modified\nones at the top), tie-breaking equal-dated refs using the implicit\n`refname` sort fallback.\n\nThis commit adds another `--sort` parameter to the `git for-each-ref`\ninvocation in `git_get_heads_list()`, ensuring that the `HEAD` ref\nalways ends up getting sorted to the top, seeing as it is typically the\n\"primary\" line of development in some sense.\n\nThis seems to be a useful change, because I can't see anywhere else in\nthe gitweb UI where we actually indicate to the user what the \"default\"\nbranch is (ie. what they'll checkout if they run `git clone`).\n\nSigned-off-by: Greg Hurrell <greg@hurrell.net>\n---\n\nOn Tue, Jun 8, 2021, at 11:02 AM, Greg Hurrell wrote:\n> On Tue, Jun 8, 2021, at 10:34 AM, Jeff King wrote:\n> >   1. break ties by name, like:\n> > \n> >        git for-each-ref --sort=refname --sort=-committerdate\n> > \n> >   2. emphasize the HEAD branch, even if it isn't the newest:\n> > \n> >        git for-each-ref --sort=refname --sort=-committerdate --sort=-HEAD\n\nI was wracking my brains over this one trying to figure out why\nit wasn't already doing the right thing based on what I see in\nref-filter.c.  It sure looks like the `--sort=refname` fallback should\nbe automatic, but I wasn't seeing it happen in my gitweb instance.\n\nTurns out there was a bug that you fixed in 7c5045fc180ed09ed4cb5 which\nmade it in soon after v2.20.4 fixing a problem. I was seeing different\nbehavior on gitweb running on Amazon Linux AMI, because that's still\nusing Git v2.18.5.\n\nSo, that means \"1\" isn't necessary. \"2\" is the only possibly interesting\nbit. I've reworded the commit text accordingly, still labeled as \"RFC\"\nto see if there is any consensus on this being a good idea or not.\n\nGreg\n\n gitweb/gitweb.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex e09e024a09..e5270b0291 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3796,7 +3796,8 @@ sub git_get_heads_list {\n \tmy @headslist;\n \n \topen my $fd, '-|', git_cmd(), 'for-each-ref',\n-\t\t($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',\n+\t\t($limit ? '--count='.($limit+1) : ()),\n+\t\t'--sort=-committerdate', '--sort=-HEAD',\n \t\t'--format=%(objectname) %(refname) %(subject)%00%(committer)',\n \t\t@patterns\n \t\tor return;\n-- \n2.29.2\n\n"},{"id":"426816","messageId":"YL/qFDPoF/0+ArAV@coredump.intra.peff.net","threadId":"55851","inReplyTo":"20210608211440.37985-1-greg@hurrell.net","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-06-08T22:07:16Z","receivedAt":"2021-06-08T22:07:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 08, 2021 at 11:14:40PM +0200, Greg Hurrell wrote:\n\n> Prior to this commit, the \"heads\" section on a gitweb summary page would\n> list the heads in `-committerdate` order (ie. the most recently-modified\n> ones at the top), tie-breaking equal-dated refs using the implicit\n> `refname` sort fallback.\n> \n> This commit adds another `--sort` parameter to the `git for-each-ref`\n> invocation in `git_get_heads_list()`, ensuring that the `HEAD` ref\n> always ends up getting sorted to the top, seeing as it is typically the\n> \"primary\" line of development in some sense.\n> \n> This seems to be a useful change, because I can't see anywhere else in\n> the gitweb UI where we actually indicate to the user what the \"default\"\n> branch is (ie. what they'll checkout if they run `git clone`).\n\nYour use of \"seems\" in the final paragraph is a leftover from the\nearlier commit message, and I think weakens your message. It's OK to\nassert that it really _is_ a useful change, I would say. :)\n\nThis patch looks good to me overall. In addition to dropping the RFC\ntag, you're more likely to get attention by having a subject line\nwithout \"Re:\" in it (so people realize it's a patch to look at, and not\njust a continuation of the discussion).\n\n> On Tue, Jun 8, 2021, at 11:02 AM, Greg Hurrell wrote:\n> > On Tue, Jun 8, 2021, at 10:34 AM, Jeff King wrote:\n> > >   1. break ties by name, like:\n> > > \n> > >        git for-each-ref --sort=refname --sort=-committerdate\n> > > \n> > >   2. emphasize the HEAD branch, even if it isn't the newest:\n> > > \n> > >        git for-each-ref --sort=refname --sort=-committerdate --sort=-HEAD\n> \n> I was wracking my brains over this one trying to figure out why\n> it wasn't already doing the right thing based on what I see in\n> ref-filter.c.  It sure looks like the `--sort=refname` fallback should\n> be automatic, but I wasn't seeing it happen in my gitweb instance.\n> \n> Turns out there was a bug that you fixed in 7c5045fc180ed09ed4cb5 which\n> made it in soon after v2.20.4 fixing a problem. I was seeing different\n> behavior on gitweb running on Amazon Linux AMI, because that's still\n> using Git v2.18.5.\n\nHeh, OK. I almost suggested \"gee, wouldn't it be nice if we used the\nrefname as a fallback tie-breaker by default\". You'd think I would\neither remember such fixes, or at least bother to look at the code. :)\n\n> So, that means \"1\" isn't necessary. \"2\" is the only possibly interesting\n> bit. I've reworded the commit text accordingly, still labeled as \"RFC\"\n> to see if there is any consensus on this being a good idea or not.\n\nYep, I agree on all counts.\n\nIn my experience gitweb doesn't tend to get a lot of interest from\nreviewers, and I consider it mostly in maintenance mode these days. So\nbe prepared for silence. In that case, I'd give it a few days and repost\nthe patch to see if Junio is interested in picking it up.\n\n-Peff\n"},{"id":"426828","messageId":"xmqqpmwvnbaz.fsf@gitster.g","threadId":"55851","inReplyTo":"20210608211440.37985-1-greg@hurrell.net","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-09T00:15:00Z","receivedAt":"2021-06-09T00:15:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg Hurrell <greg@hurrell.net> writes:\n\n> Prior to this commit, the \"heads\" section on a gitweb summary page would\n> list the heads in `-committerdate` order (ie. the most recently-modified\n> ones at the top), tie-breaking equal-dated refs using the implicit\n> `refname` sort fallback.\n\nPlease lose \"Prior to this commit\"; when we talk about the state of\nthe code, we talk about what we have _without_ the proposed change,\nso \"Currently\", etc. are noisewords.\n\nAnd then we go on to explain why the current behaviour presented in\nthe first paragraph is undesirable, and how the proposal wants to\nchange the world to a better place.  That is missing here in the\nproposed log message.\n\nAnd then we give an order to the codebase to \"become like so\" in\nimperative mood, perhaps turn this paragraph\n\n> This commit adds another `--sort` parameter to the `git for-each-ref`\n> invocation in `git_get_heads_list()`, ensuring that the `HEAD` ref\n> always ends up getting sorted to the top, seeing as it is typically the\n> \"primary\" line of development in some sense.\n\ninto:\n\n    In addition to sorting with committerdate (most recent first),\n    first show the primary branch that is pointed at with HEAD, by\n    adding another `--sort` parameter ... \n\n> This seems to be a useful change, because I can't see anywhere else in\n> the gitweb UI where we actually indicate to the user what the \"default\"\n> branch is (ie. what they'll checkout if they run `git clone`).\n\nThe justification is a bit too weak to convince readers that using\n%(HEAD) as the primary sort key to list the branch first in the list\nview is *the* best way to solve the \"it is unclear which one is the\ndefaul branch\" problem, though.  An obvious alternative would be to\nshow '*' next to such a branch just like \"git branch --list\" does,\nwithout changing the sort order at all, for example.\n\nI am not sure if using it as the primary key is a good idea, though.\nWasn't your motivating example about tiebreaking between 'main' and\n'master' that always point at the same commit?\n\n> +\t\t($limit ? '--count='.($limit+1) : ()),\n> +\t\t'--sort=-committerdate', '--sort=-HEAD',\n\nComparing %(HEAD), which is either ' ' or '*', for each ref?  It is\nbeyond \"cute\".  Nicely done.\n\n\n"},{"id":"426862","messageId":"26dbf49f-4972-4960-9383-2b69a3e6043c@www.fastmail.com","threadId":"55851","inReplyTo":"xmqqpmwvnbaz.fsf@gitster.g","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-09T07:38:16Z","receivedAt":"2021-06-09T07:38:40Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"On Wed, Jun 9, 2021, at 2:15 AM, Junio C Hamano wrote:\n> Greg Hurrell <greg@hurrell.net <mailto:greg%40hurrell.net>> writes:\n> \n> > This seems to be a useful change, because I can't see anywhere else in\n> > the gitweb UI where we actually indicate to the user what the \"default\"\n> > branch is (ie. what they'll checkout if they run `git clone`).\n> \n> The justification is a bit too weak to convince readers that using\n> %(HEAD) as the primary sort key to list the branch first in the list\n> view is *the* best way to solve the \"it is unclear which one is the\n> defaul branch\" problem, though.  An obvious alternative would be to\n> show '*' next to such a branch just like \"git branch --list\" does,\n> without changing the sort order at all, for example.\n\nYeah, I'm not 100% convinced either. Displaying a \"*\" indicator\nwould be a straightforward change to `git_heads_body()`, but it would be\na break with the visual style of all the other tables in the UI.\n\nOn the other hand, boosting `HEAD` to the top like the proposed commit\ndoes feel a bit arbitrary, given that the other list views in the UI\nseem mostly to be sorted by recency. (But then again, what `HEAD` is\nand what it means is quintessentially arbitrary, so maybe this _is_\nappropriate.)\n\nOne thing I do notice is that there is already a `current_head` CSS\nclass applied to the corresponding row, so it would be possible for the\ngitweb owner to make tha row stand out however they pleased.\n\nIn short, I am happy to amend the commit message but I fear the\nrationale for it is a bit weak. If nobody chimes in with a resounding\nendorsement, I am inclined to probably drop it.\n\n> Wasn't your motivating example about tiebreaking between 'main' and\n> 'master' that always point at the same commit?\n\nYes indeed, that was the original motivation, although after the fix\nin 7c5045fc180ed09ed4cb5 the tie-breaking by refname already has the\nequivalent desired effect, albeit coincidentally.\n\nPerhaps the sort keys _should_ be `-committerdate`, then `-HEAD`, then\n`refname` (implicit default); ie. `--sort=-HEAD --sort=-committerdate`\n(which is the opposite order to what I have in the patch). I would have\nprepared the patch in that way in the first place if my testing hadn't\nbeen confounded by the fact that I was running an older version of Git\non the installation where I was trying it out.\n\nI feel the argument for using `HEAD` as a tiebreaker is easier to make\nthan the case for using it as a primary sort key, because it is a less\ninvasive change. If there is support for that idea, I'll tweak the\npatch.\n\nCheers,\nGreg\n"},{"id":"426863","messageId":"xmqqpmwviinb.fsf@gitster.g","threadId":"55851","inReplyTo":"26dbf49f-4972-4960-9383-2b69a3e6043c@www.fastmail.com","subject":"Re: [RFC PATCH] gitweb: use HEAD as primary sort key in git_get_heads_list()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-09T07:47:36Z","receivedAt":"2021-06-09T07:47:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Greg Hurrell\" <greg@hurrell.net> writes:\n\n> One thing I do notice is that there is already a `current_head` CSS\n> class applied to the corresponding row, so it would be possible for the\n> gitweb owner to make tha row stand out however they pleased.\n>\n> In short, I am happy to amend the commit message but I fear the\n> rationale for it is a bit weak. If nobody chimes in with a resounding\n> endorsement, I am inclined to probably drop it.\n>\n>> Wasn't your motivating example about tiebreaking between 'main' and\n>> 'master' that always point at the same commit?\n>\n> Yes indeed, that was the original motivation, although after the fix\n> in 7c5045fc180ed09ed4cb5 the tie-breaking by refname already has the\n> equivalent desired effect, albeit coincidentally.\n>\n> Perhaps the sort keys _should_ be `-committerdate`, then `-HEAD`, then\n> `refname` (implicit default); ie. `--sort=-HEAD --sort=-committerdate`\n> (which is the opposite order to what I have in the patch). I would have\n> prepared the patch in that way in the first place if my testing hadn't\n> been confounded by the fact that I was running an older version of Git\n> on the installation where I was trying it out.\n>\n> I feel the argument for using `HEAD` as a tiebreaker is easier to make\n> than the case for using it as a primary sort key, because it is a less\n> invasive change. If there is support for that idea, I'll tweak the\n> patch.\n\nI agree that using HEADness as a tiebreaker is a much easier sell.\n\nAnother idea would be to give site administrators (or even to the\nend users via UI) an option to tweak how they are sorted.\n"},{"id":"426918","messageId":"20210609192806.45406-1-greg@hurrell.net","threadId":"55851","inReplyTo":"xmqqpmwviinb.fsf@gitster.g","subject":"[PATCH v2] gitweb: use HEAD as secondary sort key in git_get_heads_list()","fromName":"Greg Hurrell","fromEmail":"greg@hurrell.net","sentAt":"2021-06-09T19:28:06Z","receivedAt":"2021-06-09T19:28:35Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"The \"heads\" section on the gitweb summary page shows heads in\n`-committerdate` order (ie. the most recently-modified ones at the\ntop), tie-breaking equal-dated refs using the implicit `refname` sort\nfallback. This recency-based ordering appears in multiple places in the\nUI, such as the project listing, the tags list, and even the\nshortlog and log views.\n\nGiven two equal-dated refs, however, sorting the `HEAD` ref before\nthe non-`HEAD` ref provides more useful signal than merely sorting by\nrefname. For example, say we had \"master\" and \"trunk\" both pointing at\nthe same commit but \"trunk\" was `HEAD`, sorting \"trunk\" first helps\ncommunicate its special status as the default branch that you'll check\nout if you clone the repo.\n\nAdd `-HEAD` as a secondary sort key to the `git for-each-ref` call\nin `git_get_heads_list()` to provide the desired behavior. The most\nrecently committed refs will appear first, but `HEAD`-ness will be used\nas a tie-breaker. Note that `refname` is the implicit fallback sort key,\nwhich means that two same-dated non-`HEAD` refs will continue to be\nsorted in lexicographical order, as they are today.\n\nSigned-off-by: Greg Hurrell <greg@hurrell.net>\n---\n\nAs per list discussion, this is an easier sell than the prior version\nof this patch (which made `HEAD` the _primary_ sort key). I'm dropping\nthe RFC qualifier accordingly.\n\nSorry for the back-and-forth on this one. Using `HEAD` is the\ntie-breaker is what I wanted to do originally, but because I was\ntesting on an ancient Git version with a sorting bug, the\nstraightforward approach didn't work (:facepalm:), and I went off into\nthe weeds.\n\n gitweb/gitweb.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex e09e024a09..fbd1c20a23 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -3796,7 +3796,8 @@ sub git_get_heads_list {\n \tmy @headslist;\n \n \topen my $fd, '-|', git_cmd(), 'for-each-ref',\n-\t\t($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',\n+\t\t($limit ? '--count='.($limit+1) : ()),\n+\t\t'--sort=-HEAD', '--sort=-committerdate',\n \t\t'--format=%(objectname) %(refname) %(subject)%00%(committer)',\n \t\t@patterns\n \t\tor return;\n-- \n2.29.2\n\n"}]}