Re: [PATCH 1/1] t1403: prefer test_path_exists helper function

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Mar 4, 2025, 18:28 UTC
Message-ID: <CAPig+cTUMj-QviOuXtdAN8Ao=gbfhXK=J6oEXfdjn1cAocZ3RA@mail.gmail.com>
In-Reply-To: <CAPig+cS3QZhZ=W2WfM3T3EngaMOSV37KH4Pqp78QHzOAODtenA@mail.gmail.com>

On Tue, Mar 4, 2025 at 1:07 PM Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 13 quoted lines

> > >> >> >       remove_object() {
> > >> >> >               file=$(sha1_file "$*") &&
> > >> >> > -             test -e "$file" &&
> > >> >> > +             test_path_exists "$file" &&
> > >> >> >               rm -f "$file"
> > >> >> >       } &&
>
> However, it's still not clear to me why this function is making the
> `test -e "$file"` assertion in the first place or why the enclosing
> test should care, especially since that assertion is only checking
> that `git commit` worked correctly, but that's not the intent of this
> particular test[1]. So, `test -e "$file"` seems pointless or at least
> misleading.

Perhaps, I'm falling into the trap of assuming that a lone `git commit` in a new repository will unconditionally create a loose object, and that that will always be the case? If, down the road, `git commit` no longer works that way, then the assumption about the loose object becomes invalid, in which case I can see how the `test -e "$file"` assertion is protecting the test against that future.