From: Junio C Hamano <gitster@pobox.com>
To: Aryan Pathania <contact@aynp.dev>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [GSoC PATCH] t9400: prefer test_path_* helper functions
Date: Wed, 12 Mar 2025 11:13:56 -0700 [thread overview]
Message-ID: <xmqqplimxgkb.fsf@gitster.g> (raw)
In-Reply-To: <r5572ospfh3d7nwniod36jcy5ikv5pkmiwtqj25ll7p5ts3zay@okbxrhy77iyv> (Aryan Pathania's message of "Thu, 13 Mar 2025 02:34:52 +0900")
Aryan Pathania <contact@aynp.dev> writes:
>>This isn't quite equivalent: we've been checking that the path is not a
>>directory before, but now we verify that the path doesn't exist.
> I understand. I could not find `test_path_is_not_dir` or any equivalent
> function in `test-lib-functions.sh`. Maybe we can keep this stronger
> check. I'll mention in the commit message of next version of patch.
That is exactly Patrick suggested (go back and read it). I agree
with him that the updated stronger check is an improvement and it
deserves to be explained in the commit message.
>>We tend to use `test_path_is_file` rather than
>>`test_path_is_file_not_symlink`, but I don't mind it too much.
> I believe `test -f` is equivalent to `test_path_is_file_not_symlink` and
> is a stronger check so maybe it's fine.
Don't believe what you think you know; if you are unsure, check to
verify before you base your actions on them.
$ >this-is-file
$ ln -s this-is-file this-is-symlink
$ test -f this-is-symlink; echo $?
0
$ test -f this-is-file; echo $?
0
And if you are not unsure, then learn to be unsure more often ;-)
I do not see any reason in the part of the code Patrick commented on
to insist that gitcvs.ext.main.sqlite file must be a regular file
and not a symbolic link to another file. Both test_path_is_file
and its original before the patch, "test -f", would be more appropriate
than test_path_is_file_not_symlink, which was specifically invented
for use in t3903 where the tests used both files and symbolic links
to make sure the operation being tested would not confuse one with
the other.
> Sorry for the trouble and mistakes.
No need for that. This is for both sides to experience to learn to
work well together.
next prev parent reply other threads:[~2025-03-12 18:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-08 9:03 [GSoC PATCH] t9400: prefer test_path_* helper functions Aryan Pathania
2025-03-10 6:50 ` Patrick Steinhardt
2025-03-12 17:34 ` Aryan Pathania
2025-03-12 18:13 ` Junio C Hamano [this message]
2025-03-14 12:00 ` Aryan Pathania
2025-03-14 17:07 ` Junio C Hamano
2025-03-18 13:10 ` [GSoC PATCH v2] Use `test_path_*` helper functions instead of `test -[efd]` Aryan Pathania
2025-03-18 22:06 ` Eric Sunshine
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=xmqqplimxgkb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=contact@aynp.dev \
--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).