Re: [PATCH v3] read_gitfile(): simplify NOT_A_REPO error message

[Jeff King <peff@peff.net>]

On Tue, Jun 16, 2026 at 07:25:02AM -0700, Junio C Hamano wrote:

> >     +@@ t/t7450-bad-git-dotfiles.sh: test_expect_success 'git dirs of sibling submodules must not be nested' '
> >     + test_expect_success 'submodule git dir nesting detection must work with parallel cloning' '
> >     + 	test_must_fail git clone --recurse-submodules --jobs=2 nested clone_parallel 2>err &&
> >     + 	cat err &&
> >     +-	grep -E "(already exists|is inside git dir|not a git repository)" err &&
> >     ++	grep -E "(already exists|is inside git dir|does not point to a valid repository)" err &&
> 
> A few things.
> 
>  * Will we be happy to see only one of these possibilities, or do we
>    expect to see these once for each kind?

I imagine it is only one. This all comes from 9cf8547320 (clone: prevent
clashing git dirs when cloning submodule in parallel, 2024-01-28), and
it is expecting the nested path to cause a failure. Which failure I
guess depends on the racy ordering. If we create the inner one first,
then we probably get "already exists", and if the outer one, then "is
inside git dir". I don't know exactly what sequence yields the
NOT_A_REPO message.

But none of that is changing in this patch, just what the user-visible
text is for the NOT_A_REPO case.

I did briefly wonder if we might see "not a git repository" from a
_different_ code path, and need to catch it along with the new message.
But running successfully with --stress implies that we never see the old
one anymore.

>  * a recently started in-flight topic tries to catch bare "grep" and
>    fails until you write test_grep X-<.

Yeah. This will create a merge conflict for you, but hopefully the
resolution should be obvious. I don't think it makes sense to fix here,
as it's orthogonal to the purpose of the patch.

-Peff