On Thu, May 23, 2024 at 02:19:26PM +0100, Tom Hughes wrote:
> 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
