On Sun, 15 Jun 2025 at 05:15, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Meet Soni <meetsoni3017@xxxxxxxxx> 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
