On Tue, Feb 27, 2024 at 08:48:29AM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

There's some prior art there, I think, in how GIT_CEILING_DIRECTORIES
works, or even something like "git --literal-pathspecs", neither of
which appear in local_repo_env.

Unlike GIT_CEILING_DIRECTORIES that is more or less permanent and a
part of configuring an everyday environment for real work, I view
this --no-lazy-fetch thing as solely a debugging aid.  A repository
with promisor wouldn't be able to "fill the gap" by forbidding
on-demand fetching of promised objects while running say "git fetch"
from elsewhere and it just will die with "some objects we are
supposed to have are missing from this repository".

So I do not have a strong opinion either way, if it is more
convenient to propagate the request out to other repositories when
we run processes in two or more repositories (e.g. "git clone
--local"), or if it is more convenient to make sure that the request
is limited to the target repository.  Here is a version without the
local_repo_env[] change.

Yeah, GIT_CEILING_DIRECTORIES is maybe a bad example. But I do think
LITERAL_PATHSPECS is a better one, and the submodule-fetch example I
gave would be genuinely surprising if it behaved differently than the
superproject, I'd think.

I do agree this is probably going to mostly be a debugging aid, so it
might not matter much. But once in the wild these things tend to take on
a life of their own. ;)

----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----
Subject: [PATCH v3 3/3] git: extend --no-lazy-fetch to work across subprocesses

So anyway, this version seems good to me.

-Peff