From: Junio C Hamano <gitster@pobox.com>
To: "D. Ben Knoble" <ben.knoble@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,
Meet Soni <meetsoni3017@gmail.com>,
git@vger.kernel.org, shejialuo@gmail.com
Subject: Re: [GSoC][PATCH] builtin/refs: add 'get' subcommand
Date: Thu, 25 Sep 2025 11:43:47 -0700 [thread overview]
Message-ID: <xmqqtt0qfk4c.fsf@gitster.g> (raw)
In-Reply-To: <CALnO6CD0fCF15Vdh7_AtuWiKeXUFbU_kqV=+wAMkmABzchV=Tw@mail.gmail.com> (D. Ben Knoble's message of "Thu, 25 Sep 2025 14:08:11 -0400")
"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 ...
>> - `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.
next prev parent reply other threads:[~2025-09-25 18:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 10:45 [GSoC][PATCH] builtin/refs: add 'get' subcommand Meet Soni
2025-09-23 16:57 ` Ben Knoble
2025-09-24 6:32 ` Patrick Steinhardt
2025-09-23 21:50 ` Junio C Hamano
2025-09-24 6:32 ` Patrick Steinhardt
2025-09-24 15:29 ` Ben Knoble
2025-09-24 17:11 ` Junio C Hamano
2025-09-25 6:25 ` Patrick Steinhardt
2025-09-25 18:08 ` D. Ben Knoble
2025-09-25 18:43 ` Junio C Hamano [this message]
2025-09-24 6:32 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtt0qfk4c.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=meetsoni3017@gmail.com \
--cc=ps@pks.im \
--cc=shejialuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).