Re: [PATCH] git: extend --no-lazy-fetch to work across subprocesses

From: Jeff King <peff@peff.net>
Date: Mar 7, 2024, 09:56 UTC
Message-ID: <20240307095638.GC2650063@coredump.intra.peff.net>
In-Reply-To: <xmqq1q8xx38i.fsf@gitster.g>

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

Show 20 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > 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