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

From: Junio C Hamano <[email-masked]>
Date: Thu, 25 Sep 2025 11:43:47 -0700

"D. Ben Knoble" <[email-masked]> 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 ...

>>   - `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.