Thanks for the quick response! I've been playing with creatordate and it seems to work with with both older and newer versions of git. I am trying to understand what I did wrong. I guess you are saying that I tried to use the field committerdate, which is not available on the tags? And that the handling of this situation has changed since git/2.23? Hence I got different results? /Fredrik Den tis 10 jan. 2023 kl 14:05 skrev Martin Ågren <martin.agren@xxxxxxxxx>: > > On Tue, 10 Jan 2023 at 13:18, Jeff King <peff@xxxxxxxx> wrote: > > > > On Tue, Jan 10, 2023 at 11:54:16AM +0100, Martin Ågren wrote: > > > > > I suppose it could be argued that the '-' should be applied to the > > > fallback as well, e.g., to uphold some sort of "using '-' should give > > > the same result as piping the whole thing through tac" (i.e., respecting > > > `s->reverse` in `compare_refs()`, if you're following along in > > > 7c5045fc18). With multiple sort keys, some with '-' and some > > > without, we'd grab the '-' from the first key. It seems like that could > > > make sense, actually. > > > > I dunno. Just because you are reverse-sorting on one field doesn't > > necessarily imply that you want the tie-breaker to reverse-sort, too. I > [...] > > > I could see it depending on exactly what you're trying to do. Which > > leads me to think the rule should be as simple as possible. You can > > always do: > > > > git for-each-ref --sort=-refname --sort=-committerdate > > > > to specify exactly what you want. > > Indeed. So probably best to leave it as-is, then. > > Martin
