git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[GSoC][RFC PATCH 0/2] Add refs list subcommand

From
Meet Soni <meetsoni3017@gmail.com>
Date
Jun 14, 2025, 07:05 UTC
Message-ID
<20250614070536.17320-1-meetsoni3017@gmail.com>

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: Meet Soni
Message 1 of 5 in “Add refs list subcommand”
  1. Meet SoniJun 14, 2025
  2. [GSoC][RFC PATCH 1/2] builtin/refs: add list subcommandMeet Soni, Jun 14, 2025
  3. [GSoC][RFC PATCH 2/2] t: add tests for refs list subcommandMeet Soni, Jun 14, 2025
  4. Junio C HamanoJun 14, 2025
  5. Meet SoniJun 17, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.