From: "Yuting Zheng" <05zyt30@gmail.com>
To: "Patrick Steinhardt" <ps@pks.im>
Cc: <git@vger.kernel.org>
Subject: Re: [GSoC] Proposal Discussion: git-refs Project
Date: Thu, 27 Mar 2025 10:26:49 +0800 [thread overview]
Message-ID: <D8QOYSD6NLCS.OVF4RKHUCX0A@gmail.com> (raw)
In-Reply-To: <Z-FJ3EQdFIkQgtkR@pks.im>
Thanks for your reply!
I have reviewed the changelog and noted that Git version 2.23
introduced similar work through the addition of the git-switch and
git-restore commands, which replace some legacy commands and incorporate
various functional modifications.
After examining the updates, I have summarized the proposed work as
follows and would appreciate confirmation on whether these tasks are to be
included in the current project:
1. Code Modifications for Command Implementation:
- Implementation of new commands.
- Necessary modifications to existing commands to support these changes.
2. Test Modifications:
- Addition of tests for the new features (including help tests, basic
functionality tests, and extended feature tests).
- Updating tests for old commands to execute tests on the new commands
(for example, changing the command in git-checkout tests to git-restore).
3. Documentation Updates:
- Creating documentation for the new commands.
Updating and unifying existing documentation (including git.txt,
git-cli.txt, and git-commit.txt).
Additionally, I have a few points that require further discussion:
1. Command Migration:
Upon reviewing the commands slated for replacement (e.g., git-update-ref(1),
git-for-each-ref(1), git-show-ref(1), git-pack-refs(1), and
git-symbolic-ref), it seems that migrating their functionality into a
subcommand of git-refs could be sufficient. Could you please confirm if
this approach meets our project requirements without introducing
additional functionality?
2. Function Call Integration:
Regarding migration, is it acceptable to directly invoke the legacy command
functions by passing parameters from the new command functions?
3. Test Retention:
Lastly, should we retain the original tests for the legacy commands, or
should they be fully replaced with tests for the new implementations?
I appreciate your guidance and look forward to your feedback on these points.
Best regards,
Zheng Yuting
next prev parent reply other threads:[~2025-03-27 2:27 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 [this message]
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
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=D8QOYSD6NLCS.OVF4RKHUCX0A@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 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.