Re: [GSoC][PATCH] builtin/refs: add 'get' subcommand

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 25, 2025, 18:43 UTC
Message-ID: <xmqqtt0qfk4c.fsf@gitster.g>
In-Reply-To: <CALnO6CD0fCF15Vdh7_AtuWiKeXUFbU_kqV=+wAMkmABzchV=Tw@mail.gmail.com>

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

>> I don't quite think so. The problem is that we have so many different
>> tools that relate to refs, and you have to remember all of them:

Yup, but ...

Show 17 quoted lines

>>   - `git show-refs --verify` to read a single reference, unless it's a
>>     symbolic reference.
>>
>>   - `git symbolic-ref` to read symbolic refs.
>>
>>   - `git show-refs --exists` to check a reference for existence.
>>
>>   - `git show-ref` and `git for-each-ref` to list references.
>>
>>   - `git pack-refs` to optimize references.
>>
>>   - `git update-refs` to update references`
>>
>> I'd claim that this is quite hard to remember. So...
>
> Agreed! To be clear: me asking questions should be taken as support
> for this exercise :)

... the same thing can be said about subcommands of "git refs", all of which you have to remember. I am not sure if this "everything under "git refs" really makes much difference.

>> That's also where the "git refs get" proposal comes from. Sure, you can
>> use `git show-refs --verify`, potentially with a `--no-dereference` flag
>> if you want to read normal refs. But I would claim that this is almost
>> impossible to discover without searching through our manpages.

So? That still does not indicate adding yet another command to do it is the right solution to the discover-ability problem. Instead of shifting and moving things around, reimplementing things to risk introducing new bugs, wouldn't it be more productive to spend effort on improving the documentation and possibly filling the gaps of features?

Thanks.