On Tue, Feb 27, 2024 at 08:48:29AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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
