Re: [GSoC][RFC PATCH 0/2] Add refs list subcommand

From: Meet Soni <meetsoni3017@gmail.com>
Date: Jun 17, 2025, 11:51 UTC
Message-ID: <CAPhwyn3N2O4OgPvEgec8C7Kvb1793s_KLq1u2y1tx6-msG+gFg@mail.gmail.com>
In-Reply-To: <xmqqsek16g6c.fsf@gitster.g>

On Sun, 15 Jun 2025 at 05:15, Junio C Hamano <gitster@pobox.com> wrote:

Show 28 quoted lines

>
> Meet Soni <meetsoni3017@gmail.com> writes:
>
> > This RFC is meant to start a broader discussion on:
> >
> >   - The desired default behavior of pattern matching in git refs list
> >
> >   - Which features from both git-show-ref and git-for-each-ref should be
> >     preserved, rethought, or dropped
> >
> >   - How much backward compatibility we want to offer, and through what
> >     interface (e.g., compatibility flags)
> >
> > Feedback and thoughts on these topics would be very welcome.
>
> In addition to these three points, 0th point perhaps is "Is it
> desirable to unify these two commands in the first place?"
>
> I only use "show-ref" when I care about a single ref in a script,
> expecting to be able to switch on its exit status.  Everything else
> I'd use for-each-ref.
>
> But then that particular unique advantage of show-ref over for-each-ref
> can be done with "rev-parse --verify".
>
> So, I'd rather not to see yet another command to do the same thing.
> Rather, is it insufficient to just use for-each-ref or rev-parse,
> let the sleeping show-ref alone, and be happy?

The broader motivation behind this effort (and the overarching GSoC project) has been to reduce fragmentation in ref-related functionality by gradually consolidating it under the git refs umbrella, aiming for consistency and discoverability.

Your point about rev-parse --verify covering show-ref's main utility is well taken. If that truly makes show-ref redundant, then perhaps it makes more sense to focus consolidation efforts around for-each-ref instead.

One concern I have is that if we simply replicate for-each-ref under a new name, we may still face the same question: what does this new command add that the old one doesn't already handle?

I'd love to hear thoughts on what a modernized or simplified ref-listing interface could look like. Are there features or changes worth exploring that could justify the consolidation?

Thanks, Meet