patcht0001: replace "test [-d|-f]" with test_path_is_* functions

> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index 3235ab4d53..c72a28d3a5 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -6,7 +6,7 @@ TEST_PASSES_SANITIZE_LEAK=true
>  . ./test-lib.sh
>
>  check_config () {
> -	if test -d "$1" && test -f "$1/config" && test -d "$1/refs"
> +	if test_path_is_dir "$1" && test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
>  	then
>  		: happy
>  	else

>> -	if test -d "$1" && test -f "$1/config" && test -d "$1/refs"
>> +	if test_path_is_dir "$1" && test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
>>  	then
>>  		: happy
>>  	else
>
> Looks very reasonable to me. Indeed, this line comes from 6adcca3fe8
> (Fix initialization of a bare repository, 2007-08-27) which predates
> 2caf20c52b (test-lib: user-friendly alternatives to test [-d|-f|-e],
> 2010-08-10) when these helpers were originally introduced.
>
> I thought that we could probably just shorten this to calling
> "test_path_is_file" twice: once for "$1/config" and a second time for
> "$1/refs", but that assumes "$1" is non-empty. And to ensure that you'd
> need another check, which amounts to the same amount of code overall.

>
> Taylor Blau <me@ttaylorr.com> writes:
>
> >> -    if test -d "$1" && test -f "$1/config" && test -d "$1/refs"
> >> +    if test_path_is_dir "$1" && test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
> >>      then
> >>              : happy
> >>      else
> >
> > Looks very reasonable to me. Indeed, this line comes from 6adcca3fe8
> > (Fix initialization of a bare repository, 2007-08-27) which predates
> > 2caf20c52b (test-lib: user-friendly alternatives to test [-d|-f|-e],
> > 2010-08-10) when these helpers were originally introduced.
> >
> > I thought that we could probably just shorten this to calling
> > "test_path_is_file" twice: once for "$1/config" and a second time for
> > "$1/refs", but that assumes "$1" is non-empty. And to ensure that you'd
> > need another check, which amounts to the same amount of code overall.
>
> I had the same thought.
>
> Since the first "$GIT_DIR must be a directory" matters only when the
> caller is crazy enough to have a bare repository at the root of the
> filesystem and to think that it is a good idea to say "" is the
> "$GIT_DIR" (in which case, "test -d ''" would fail, even though the
> tests for /config and /refs are checking the right thing), I do not
> see much downside from omitting the first one, but I think that is
> something we need to do _outside_ the topic of this change, which is
> purely "modernize, using the helpers we already have, without
> changing what we do"
>

>
> Taylor Blau <me@ttaylorr.com> writes:
>
> >> -    if test -d "$1" && test -f "$1/config" && test -d "$1/refs"
> >> +    if test_path_is_dir "$1" && test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
> >>      then
> >>              : happy
> >>      else
> >
> > Looks very reasonable to me. Indeed, this line comes from 6adcca3fe8
> > (Fix initialization of a bare repository, 2007-08-27) which predates
> > 2caf20c52b (test-lib: user-friendly alternatives to test [-d|-f|-e],
> > 2010-08-10) when these helpers were originally introduced.
> >
> > I thought that we could probably just shorten this to calling
> > "test_path_is_file" twice: once for "$1/config" and a second time for
> > "$1/refs", but that assumes "$1" is non-empty. And to ensure that you'd
> > need another check, which amounts to the same amount of code overall.
>
> I had the same thought.
>
> Since the first "$GIT_DIR must be a directory" matters only when the
> caller is crazy enough to have a bare repository at the root of the
> filesystem and to think that it is a good idea to say "" is the
> "$GIT_DIR" (in which case, "test -d ''" would fail, even though the
> tests for /config and /refs are checking the right thing), I do not
> see much downside from omitting the first one, but I think that is
> something we need to do _outside_ the topic of this change, which is
> purely "modernize, using the helpers we already have, without
> changing what we do".
>
>

>
> Shaoxuan Yuan <shaoxuan.yuan02@gmail.com> writes:
>
> > Since I didn't see this change in seen or next, do you plan to apply it?
>
> I actually wasn't, as my understanding of it was primarily your
> practice.

> On Thu, Feb 10, 2022 at 3:12 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Shaoxuan Yuan <shaoxuan.yuan02@gmail.com> writes:
>>
>> > Since I didn't see this change in seen or next, do you plan to apply it?
>>
>> I actually wasn't, as my understanding of it was primarily your
>> practice.
>
> Understood, thanks for the reply.

> parked in the 'seen' branch.  As the script is quiescent right now,
> I do not mind merging it down, now we spent more time on it ;-)
>
>  t/t0001-init.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index c72a28d3a5..d479303efa 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -6,7 +6,8 @@ TEST_PASSES_SANITIZE_LEAK=true
>  . ./test-lib.sh
>
>  check_config () {
> -       if test_path_is_dir "$1" && test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
> +       if test_path_is_dir "$1" &&
> +          test_path_is_file "$1/config" && test_path_is_dir "$1/refs"
>         then
>                 : happy
>         else

> On Fri, Feb 11, 2022 at 1:23 AM Junio C Hamano <gitster@pobox.com> wrote:
>> FWIW, I have the posted patch plus the following SQUASH??? fix-up
>
> I'm not so sure what does "SQUASH???" mean especially the three
> question marks, i.e. is it just an incidental text or a commit message
> convention?
> Is it for the convenience of grepping through the
> "git log" outputs (cause I found the commit 50d631c71c right away by
> grepping through the "git log" output)?

> On Fri, Feb 11, 2022 at 1:23 AM Junio C Hamano <gitster@pobox.com> wrote:
> > FWIW, I have the posted patch plus the following SQUASH??? fix-up
>
> I'm not so sure what does "SQUASH???" mean especially the three
> question marks, i.e. is it just an incidental text or a commit message
> convention?

>
> On Mon, Feb 14, 2022 at 9:32 AM Shaoxuan Yuan <shaoxuan.yuan02@gmail.com> wrote:
> > On Fri, Feb 11, 2022 at 1:23 AM Junio C Hamano <gitster@pobox.com> wrote:
> > > FWIW, I have the posted patch plus the following SQUASH??? fix-up
> >
> > I'm not so sure what does "SQUASH???" mean especially the three
> > question marks, i.e. is it just an incidental text or a commit message
> > convention?
>
> It means that you might want to squash the fix-up commit or a similar
> commit into your commit (or one of your commits in case of a
> commit/patch series), and then resubmit a new version.
>
> > Is it for the convenience of grepping through the
> > "git log" outputs (cause I found the commit 50d631c71c right away by
> > grepping through the "git log" output)?
>
> It is for convenience that it's named "SQUASH???" as everyone (who is
> familiar with the mailing list) then knows what needs to be done on
> the proposed commit(s).

> > > parked in the 'seen' branch.  As the script is quiescent right now,
> > > I do not mind merging it down, now we spent more time on it ;-)
>
> Alternatively as Junio says he is ok with merging that down, you might
> just accept his offer and he will squash the "SQUASH???" commit for
> you before merging the result into the "next" branch.