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

From: Jeff King <peff@peff.net>
Date: May 3, 2020, 09:09 UTC
Message-ID: <20200503090952.GA170768@coredump.intra.peff.net>
In-Reply-To: <CAGqZTUvuJgZH-YUxDTYunng3QD4-wwPgquZX1P=1P1R=Ku0s2g@mail.gmail.com>

On Sat, May 02, 2020 at 10:31:50PM +0200, clime wrote:

Show 14 quoted lines

> 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