From: Zheng Yuting <05zyt30@gmail.com>
To: 05zyt30@gmail.com
Cc: git@vger.kernel.org
Subject: Discussion on git-refs list Implementation and Possible Approaches
Date: Thu, 3 Apr 2025 23:44:04 +0800 [thread overview]
Message-ID: <20250403154404.3459805-1-05ZYT30@gmail.com> (raw)
In-Reply-To: <20250329150248.2274482-1-05ZYT30@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]
After an initial review of the code and documentation for `git-show-ref`
and `git-for-each-ref`, I believe the functionality of the `git-refs list`
subcommand can be categorized into two major types:
1. **Filtering options**
- In `git-for-each-ref`:
- `--count`
- `--sort=<key>`
- `--points-at=<object>`
- `--merged[=<object>]`
- `--no-merged[=<object>]`
- `--contains[=<object>]`
- `--no-contains[=<object>]`
- `--omit-empty`
- `--exclude=<pattern>`
- `--include-root-refs`
- In `git-show-ref`:
- `--head`
- `--branches`
- `--tags`
- `--exclude-existing[=<pattern>]`
2. **Formatting options**
- In `git-for-each-ref`:
- `--format=<format>`
- `--color[=<when>]`
- `--tcl`
- `--shell`
- `--perl`
- In `git-show-ref`:
- `--dereference`
- `--hash`
Additionally, for filtering functionality, the `--ignore-case` option
from `git-for-each-ref` should be supported across the board.
**Note**: The `--verify`, `--quiet` and `--exist` options in
`git-show-ref` are intended to be implemented as separate
`git-refs` subcommands and are not within the scope of this
discussion.
## Implementation Considerations
At this point, I haven't come up with a perfect implementation
plan, as each approach has some issues:
### Approach 1:
`git-refs list` would support both filtering and formatting options,
meaning it could provide:
- Filtered output
- Formatted output
- Combined filter + format output
However, I see two potential problems with this approach:
1. Would it make the `list` subcommand too complex?
2. The performance could be worse than `git-for-each-ref`.
### Approach 2:
Split the functionality into two separate subcommands:
- `git-refs filter`: Handles filtering and filter + format output
- `git-refs show`: Supports formatting options
For implementation, my initial thought is that `git-refs filter` could
reuse the formatting options from `git-refs show`. Perhaps this could
work similarly to how `git-add --patch` and `git-restore --patch`
share logic, though I haven’t thoroughly reviewed that part of the
code yet. Would this be a reasonable approach?
## Overall Plan
If Approach 2 is preferable, I could start with `git-refs show` since it
only deals with basic ref listing and formatting. I would then make
the formatting code more reusable to support `git-refs filter`, which
would focus solely on filtering.
If Approach 1 is chosen, the implementation plan would remain the
same, but everything would be handled within a single `git-refs list`
command.
I would appreciate any feedback or alternative suggestions on the
best way to structure this functionality.
Thanks!
next prev parent reply other threads:[~2025-04-03 15:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-23 13:36 [GSoC] Proposal Discussion: git-refs Project Yuting Zheng
2025-03-24 12:02 ` Patrick Steinhardt
2025-03-27 2:26 ` Yuting Zheng
2025-03-28 13:45 ` shejialuo
2025-03-29 14:54 ` Yuting Zheng
2025-03-29 15:02 ` [GSoC] git-refs proposal draft Zheng Yuting
2025-03-31 9:42 ` Patrick Steinhardt
2025-04-01 13:37 ` Yuting Zheng
2025-04-02 8:02 ` Patrick Steinhardt
2025-04-03 15:44 ` Zheng Yuting [this message]
2025-04-04 11:08 ` Discussion on git-refs list Implementation and Possible Approaches Karthik Nayak
2025-04-04 15:25 ` Yuting Zheng
2025-04-04 11:15 ` Patrick Steinhardt
[not found] ` <CAMvj1+rMY2YR8_GGFeDoJ6HCiVDusZZk9fAguKh=kbctHO=2Qg@mail.gmail.com>
2025-04-04 15:20 ` Fwd: " Yuting Zheng
2025-04-04 15:26 ` Yuting Zheng
2025-04-04 15:16 ` Yuting Zheng
2025-04-06 6:08 ` [GSoC] git-refs proposal v2 Yuting Zheng
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=20250403154404.3459805-1-05ZYT30@gmail.com \
--to=05zyt30@gmail.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.