From: Meet Soni <meetsoni3017@gmail•com>
To: git@vger•kernel.org
Cc: Meet Soni <meetsoni3017@gmail•com>
Subject: [GSoC][RFC PATCH 0/2] Add refs list subcommand
Date: Sat, 14 Jun 2025 12:35:34 +0530 [thread overview]
Message-ID: <20250614070536.17320-1-meetsoni3017@gmail.com> (raw)
This patch series introduces the git refs list subcommand, as part of a
longer-term goal to consolidate and modernize ref listing functionality
currently split between git-show-ref(1) and git-for-each-ref(1).
The initial implementation focuses on mirroring the behavior of
git-show-ref, providing support for filtering by --branches, --tags, and
--head, and implementing pattern matching similar to the legacy command.
This ensures backward compatibility.
That said, git-for-each-ref(1) offers more flexible pattern matching and
we acknowledge that its style may be a better fit in the long run. As
such, this RFC deliberately starts with the show-ref matching semantics
to solicit feedback on whether to switch to for-each-ref style matching
as the default, with a compatibility flag to preserve legacy behavior.
It's also worth highlighting that several options from git-show-ref are
intended to be supported in the git refs list subcommand. These include
flags such as '--abbrev', '--quiet', '--dereference', '--hash', and
'--exclude-existing'. While this series focuses on core functionality
and pattern matching, these additional options are within scope for
future patches.
Additionally, the git-for-each-ref(1) command offers a rich set of
features that would be valuable to incorporate into git refs list. At
this point, all of its existing options appear to provide meaningful
functionality, and my current thinking is to support them incrementally
as part of expanding this subcommand. I'd appreciate feedback on whether
there are any options that should be reconsidered or excluded in this
consolidation effort.
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.
Meet Soni (2):
builtin/refs: add list subcommand
t: add tests for refs list subcommand
Documentation/git-refs.adoc | 25 ++++++++
builtin/refs.c | 110 ++++++++++++++++++++++++++++++++++++
t/meson.build | 1 +
t/t1461-refs-list.sh | 95 +++++++++++++++++++++++++++++++
4 files changed, 231 insertions(+)
create mode 100755 t/t1461-refs-list.sh
--
2.34.1
next reply other threads:[~2025-06-14 7:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-14 7:05 Meet Soni [this message]
2025-06-14 7:05 ` [GSoC][RFC PATCH 1/2] builtin/refs: add list subcommand Meet Soni
2025-06-14 7:05 ` [GSoC][RFC PATCH 2/2] t: add tests for refs " Meet Soni
2025-06-14 23:45 ` [GSoC][RFC PATCH 0/2] Add " Junio C Hamano
2025-06-17 11:51 ` Meet Soni
-- strict thread matches above, loose matches on Subject: below --
2025-06-27 7:49 Meet Soni
2025-06-27 18:03 ` Junio C Hamano
2025-06-28 8:05 ` shejialuo
2025-06-30 14:05 ` Junio C Hamano
2025-07-06 12:58 ` shejialuo
2025-06-30 3:53 ` Meet Soni
2025-06-30 20:10 ` Junio C Hamano
2025-07-09 13:36 ` 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=20250614070536.17320-1-meetsoni3017@gmail.com \
--to=meetsoni3017@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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