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

[Junio C Hamano <gitster@pobox.com>]

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

>>> Perhaps "show-ref --verify --no-deref" or something that does not
>>> dereference but works directly on a symbolic ref?
>> 
>> For now: yes, it's more difficult to discover for sure. But users will
>> adjust over time as they get more familiar with git-refs(1), and from
>> thereon I think it will become significantly easier to discover that
>> subcommand.

But unfortunately, that is a tautology, isn't it?  With the same
effort to advertise git-refs to make it more familiar to the
"users", you can make "show-ref" familiar to the same "users", and
problem solved, without a need to do anything to "git-refs"?

> I think this goes to perhaps some of my unasked questions: who is
> the target audience? My experience suggest that most
> mostly-porcelain users don’t acquire familiarity with scripting
> commands, so it sounds like we’re talking about script-writers
> here (and in the commit message).
>
> But how do we encourage script writers to discover these things? 🤔 Hm. 

Great question.  I understand what the patch author is trying to
achieve (i.e. "consolidate ref-related functionality into git-refs",
which is the title of GSoC project [*]), but what are we, as Git
project, trying to achive by "consolidating"?  I often cannot shake
the feeling that it may a make-work job without a clear answer to
that question.  Or perhps xkcd.com/927/?

Perhaps the hope is to have a single kitchen sink "git refs" command
that does anything related to "refs", so that they only need to
learn this single command (and unlearn all the previous experiences
they gained) and after that, they do not have to "discover" more
things?




[Reference]

* https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q