From: Yuting Zheng <05zyt30@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: Discussion on git-refs list Implementation and Possible Approaches
Date: Fri, 4 Apr 2025 23:26:45 +0800 [thread overview]
Message-ID: <CAMvj1+qer9--SteiYM+ZLJ2evJos-MGC_RPssHDhB-FwYaWPyw@mail.gmail.com> (raw)
In-Reply-To: <Z--_TvQ9MXgjxqOV@pks.im>
Thanks for your review!
> Another factor is the default format that these two commands use which
> differs. I would heavily lean towards using the format exposed by `git
> show-ref` because it doesn't require us to hit the ODB, and thus it is
> way more efficient. This has bitten me quite often already.
Thanks for your reminder! I will explain this output format in my next
proposal, and I agree that we should adopt the `git show-ref` format for
its superior efficiency.
> I don't think it would, both are orthogonal to one another. I don't
> think people _only_ want to format or _only_ want to filter. Quite
> often, they'll want to do both at the same time.
>
On the topic of filtering and formatting, I plan to implement these as
basic functions that work together seamlessly. In other words, the filter
and format functionalities will be integrated (without being exposed as
separate options) so that users can combine them as needed. I will
submit another email for further discussion about options.
> > 2. The performance could be worse than `git-for-each-ref`.
>
> Why is that? git-for-each-ref(1) already knows to filter and format, so
> I'd expect the performance to be roughly the same. In fact, I think we
> would be able to improve performance if we changed the default format as
> mentioned above.
>
I am concerned that iterating over all available options might introduce
additional overhead.
>
> I don't think this plan would make sense as it would mean that current
> users of git-for-each-ref(1) wouldn't be able to migrate.
>
Finally, in light of your feedback and Karthik’s, I have decided that
Approach 1 will be my final plan.
Thanks !
Zheng Yuting
next prev parent reply other threads:[~2025-04-04 15:26 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 ` Discussion on git-refs list Implementation and Possible Approaches Zheng Yuting
2025-04-04 11:08 ` 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 [this message]
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=CAMvj1+qer9--SteiYM+ZLJ2evJos-MGC_RPssHDhB-FwYaWPyw@mail.gmail.com \
--to=05zyt30@gmail.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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).