Re: git for-each-ref - sorting by multiple keys
Awesome, thanks!
On Sun, 3 May 2020 at 11:09, Jeff King <peff@peff.net> wrote:
Show 36 quoted lines
>
> 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(-)
>
> -Peffclime <clime7@gmail.com>