From: Junio C Hamano <gitster@pobox.com>
To: COGONI Guillaume <cogoni.guillaume@gmail.com>
Cc: git@vger.kernel.org, git.jonathan.bressat@gmail.com,
guillaume.cogoni@gmail.com, matthieu.moy@univ-lyon1.fr
Subject: Re: [PATCH] t/t3903-stash.sh: replace test [-d|-f] with test_path_is_*
Date: Fri, 11 Feb 2022 10:02:14 -0800 [thread overview]
Message-ID: <xmqq5yplcme1.fsf@gitster.g> (raw)
In-Reply-To: <20220211134655.1149320-1-cogoni.guillaume@gmail.com> (COGONI Guillaume's message of "Fri, 11 Feb 2022 14:46:55 +0100")
COGONI Guillaume <cogoni.guillaume@gmail.com> writes:
> @@ -390,7 +390,7 @@ test_expect_success SYMLINKS 'stash file to symlink' '
> rm file &&
> ln -s file2 file &&
> git stash save "file to symlink" &&
> - test -f file &&
> + test_path_is_file file &&
This is not wrong per-se, and I know I shouldn't demand too much
from a practice patch like this, but for a real patch, I hope
contributors carefully check if the original is doing the right
thing.
What does the code want to do?
- The starting state, HEAD, has a 'file' that is a regular file.
- We remove and replace 'file' with a symbolic link.
- We stash.
So the expectation here is at this point, 'file' is a regular file
and not a symbolic link. Some anticipated errors are that "stash
save" fails to turn 'file' back to a regular file include leaving it
as a symbolic link and successfully remove the symblic link version
but somehow failing to recreate a regular file.
Is "test -f file", which was used by the original, the right way to
detect these possible errors?
Whey file2 is a regular file that exists and file is a symbolic link
points at it, i.e. if "stash save" fails to operate, "test -f file" would
still say "Yes, it is a file".
$ >regular-file
$ rm -f missing-file
$ ln -s regular-file link-to-file
$ ln -s missing-file link-to-missing
$ test -f regular-file; echo $?
0
$ test -f link-to-file; echo $?
0
$ test -f link-to-missing; echo $?
1
$ test ! -h regular-file && test -f regular-file; echo $?
0
$ test ! -h link-to-file && test -f link-to-file; echo $?
1
As "test_path_is_file" is merely a wrapper around "test -f", this
patch may not make it any worse, but I am skeptical if this is a
good idea, given that possible follow-on project may be one or more
of these:
* verify that all existing users of test_path_is_file want to
reject a symlink to file, and add 'test ! -h "$1" &&' to the
implementation of the test helper in t/test-lib-functions.sh
(we may want to do the same for test_path_is_dir).
* introduce test_path_is_symlink and use it appropriately. This
will be a more verbose version of "test -h".
* introduce test_path_is_file_not_symlink and use it here.
If the proposed log message leaves a note on the issue, e.g.
There are dubious uses of "test -f" in the original that should
be differentiating a regular file and a symbolic link to an
existing regular file, but this mechanical conversion patch does
not fix them.
it would be nicer.
Thanks.
next prev parent reply other threads:[~2022-02-11 18:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 13:46 [PATCH] t/t3903-stash.sh: replace test [-d|-f] with test_path_is_* COGONI Guillaume
2022-02-11 18:02 ` Junio C Hamano [this message]
2022-02-14 20:22 ` Cogoni Guillaume
2022-02-15 22:13 ` Ævar Arnfjörð Bjarmason
2022-02-18 17:10 ` [PATCH v2 0/2] replace test [-f|-d] with more verbose functions COGONI Guillaume
2022-02-18 17:12 ` COGONI Guillaume
2022-02-18 17:12 ` [PATCH v2 1/2] t/t3903-stash.sh: replace test [-d|-f] with test_path_is_* COGONI Guillaume
2022-02-18 17:12 ` [PATCH v2 2/2] Add new tests functions like test_path_is_* COGONI Guillaume
2022-02-18 18:48 ` Junio C Hamano
2022-02-22 21:54 ` [PATCH v3 0/3] replace test [-f|-d] with more verbose functions COGONI Guillaume
2022-02-22 21:54 ` [PATCH v3 1/3] t/t3903-stash.sh: replace test [-d|-f] with test_path_is_* COGONI Guillaume
2022-02-22 21:54 ` [PATCH v3 2/3] tests: allow testing if a path is truly a file or a directory COGONI Guillaume
2022-02-22 21:54 ` [PATCH v3 3/3] tests: make the code more readable COGONI Guillaume
2022-02-23 22:59 ` [PATCH v3 0/3] replace test [-f|-d] with more verbose functions Junio C Hamano
2022-02-24 18:22 ` Cogoni Guillaume
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5yplcme1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=cogoni.guillaume@gmail.com \
--cc=git.jonathan.bressat@gmail.com \
--cc=git@vger.kernel.org \
--cc=guillaume.cogoni@gmail.com \
--cc=matthieu.moy@univ-lyon1.fr \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).