Re: [PATCH] promisor-remote: add promisor.quiet configuration option

From: Jeff King <peff@peff.net>
Date: May 25, 2024, 05:29 UTC
Message-ID: <20240525052946.GD1895047@coredump.intra.peff.net>
In-Reply-To: <20240523131926.1959245-1-tom@compton.nu>

On Thu, May 23, 2024 at 02:19:26PM +0100, Tom Hughes wrote:

Show 6 quoted lines

> Add a configuration optione to allow output from the promisor
> fetching objects to be suppressed/
> 
> This allows us to stop commands like git blame being swamped
> with progress messages and gc notifications from the promisor
> when used in a partial clone.

I'm not at all opposed to providing a way to suppress this, but I feel like in the long run, the more fundamental issue is that git-blame kicks off a zillion fetches as it traverses. That's not only ugly but it's also horribly inefficient.

In an ideal world we'd queue all of the blobs we need, do a single fetch, and then compute the blame on the result. That's probably easier said than done, though we have done it in other spots (e.g., for checkout).

In terms of user experience, you can simulate it with something like:

  # fault in all of the necessary blobs in one batch
  git rev-list HEAD -- $file |
  git diff-tree --stdin --format= -r --diff-filter=d -m --raw -- $file |
  awk '{print $4}' |
  git -c fetch.negotiationAlgorithm=noop \
      fetch --no-tags --no-write-fetch-head --recurse-submodules=no \
      --filter=blob:none --stdin

  git blame $file

Obviously that command is horrid and not something users should have to care about. But if we had some way for blame to say "hey, I am traversing from X..Y, looking at these pathspecs", then our first lazy-fetch could try to grab all of them. And I think the same would be the case for "git log -p", and so on.

Doing a separate traversal isn't maximally efficient, but it might not be too bad in practice (and we could even do partial traversals to balance chunking versus responsiveness, though in the case of non-incremental blame we need everything before we generate an answer anyway).

But anyway, I bring it up here because I think once we reach that end state, it won't be as interesting to turn off the fetch progress.

-Peff