Re: git for-each-ref - sorting by multiple keys

[clime <clime7@gmail.com>]

Awesome, thanks!

On Sun, 3 May 2020 at 11:09, Jeff King <peff@peff.net> wrote:
>
> On Sat, May 02, 2020 at 10:31:50PM +0200, clime wrote:
>
> > I have the following command:
> >
> > /usr/bin/git for-each-ref --merged="${GIT_HEAD-HEAD}"
> > --sort='-taggerdate' --sort='-*committerdate'
> > --format="%(*committerdate)|%(taggerdate)|%(tag)" refs/tags
> >
> > I thought this will use: -*commiterdate as a primary key and
> > -taggerdate as a secondary. According to man page for --sort: "You may
> > use the --sort=<key> option multiple times, in which case the last key
> > becomes the primary key."
> >
> > But that doesn't seem to be the case. I created a repo with a single
> > commit and created annotated tags on the commit in the following
> > order:
>
> It looks like this has been quite broken since 2015 and nobody noticed. :(
>
> Thanks for your reproduction recipe; using times is a critical part of
> the bug. Here's a fix, plus a fix for a related bug I noticed while
> working on it (the second one fixes your bug).
>
>   [1/2]: ref-filter: apply --ignore-case to all sorting keys
>   [2/2]: ref-filter: apply fallback refname sort only after all user sorts
>
>  builtin/branch.c        |  2 +-
>  builtin/for-each-ref.c  |  2 +-
>  builtin/tag.c           |  2 +-
>  ref-filter.c            | 13 +++++-
>  ref-filter.h            |  2 +
>  t/t6300-for-each-ref.sh | 94 ++++++++++++++++++++++++++++++++++++++---
>  6 files changed, 104 insertions(+), 11 deletions(-)
>
> -Peff