From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Usman Akinyemi <usmanakinyemi202@gmail.com>
Cc: Shashank S via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Christian Couder <christian.couder@gmail.com>,
Siddharth Asthana <siddharthasthana31@gmail.com>,
Shashank S <shashu8660@gmail.com>
Subject: Re: [PATCH] t0081: modernize the code testing whether a file exists
Date: Thu, 15 Oct 2026 17:13:33 +0530 [thread overview]
Message-ID: <9c905a79-22a2-4db2-b434-00ad8a287300@gmail.com> (raw)
In-Reply-To: <xmqqzewgosyw.fsf@gitster.g>
On 10/15/26 03:17, Junio C Hamano wrote:
> Usman Akinyemi <usmanakinyemi202@gmail.com> writes:
>
>>> From: Shashank <shashu8660@gmail.com>
>>>
>>> Replace the old-style shell `test -f` command with Git's modern
>>> `test_path_is_file`.
>>>
>>> This instance was found using:
>>> `git grep "test -[efd]" t/'
>> This is not necessary, remove it.
>
> Since many candidates are working on similar microprojects (which is
> fine) and making the same mistakes (which is expected), perhaps mentors
> should tell them to read the review exchanges on other candidates'
> patches and learn from them, instead of or in addition to giving the
> same advice repeatedly.
I agree that it is a good advice to ask candidate to read other
candidates' patches. We do recommend this in our guide related to
working on Microprojects:
https://git.github.io/General-Microproject-Information/#research-existing-related-work
That said, I just wanted to highlight one thing. In the Microproject
ideas page[1], we have the following for this specific idea:
Notes
- Start small: Pick a test file with just a few instances to convert
- Run the test suite after your changes to ensure nothing breaks
- Follow Git’s commit message style
- Include which command you used to find the instances in your commit
message
So, we can't really blame the candidates for including the command in
the commit message. It is our mistake asking them to include it in the
first place when we don't prefer it to be present there.
I raised a PR to fix that:
https://github.com/git/git.github.io/pull/875
[1]: https://git.github.io/SoC-2026-Microprojects/
--
Sivaraam
next prev parent reply other threads:[~2026-10-15 11:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 7:26 [PATCH] t0081: modernize the code testing whether a file exists Shashank S via GitGitGadget
2026-10-14 9:49 ` Usman Akinyemi
2026-10-14 21:47 ` Junio C Hamano
2026-10-15 7:02 ` Shashank S
2026-10-15 11:43 ` Kaartic Sivaraam [this message]
2026-10-15 17:10 ` Junio C Hamano
2026-10-15 6:51 ` Shashank S
2026-10-15 10:47 ` [PATCH v2] [Outreachy] " Shashank S via GitGitGadget
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=9c905a79-22a2-4db2-b434-00ad8a287300@gmail.com \
--to=kaartic.sivaraam@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=shashu8660@gmail.com \
--cc=siddharthasthana31@gmail.com \
--cc=usmanakinyemi202@gmail.com \
/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.