When doing a shallow git clone, how to limit git blame to the depth of the clone?

Question

I have a short-lived process which does a shallow clone (e.g. git clone --depth 50 <repo>) of a huge repo with ancient history.

Part of the process, in some conditions, it uses runs git blame on certain lines of certain files. In some cases, where the line of the file was last changed in a very early commit of the repo, the git blame command takes a very long time. I think it lazy-downloads the history again and again until it reaches the old commit.

In my case, if the blame was not part of the shallow clone, I don't care about it.

Is there a way to limit git blame to the already downloaded commits and return an error message (or any other info I can parse) and not lazy-load older commits?

I tried using:

git blame -L 10,10 <SHA>^50..<SHA> -- file.txt

and

git blame -L 10,10 <SHA>~50..<SHA> -- file.txt

but in both cases I sometime get the following error:

fatal: bad revision

UPDATE: I failed to mention that I'm also using treeless --filter=tree:0

I get the following (repeating) messages in stderr:

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.

Answer 1

I think it lazy-downloads the history again and again until it reaches the old commit.

No, it doesn't. When used with a shallow clone, neither git blame nor any other command will "lazy-download" history beyond the shallow horizon (partial cloning with git clone --filter is different; objects that were filtered out at clone time may be lazy-fetched, because you have a full commit history; it's just missing some of its trees and/or blobs).

The behavior you're asking for is already the way git works. git blame in a shallow clone just attributes any changes made before the shallow horizon to the first commit (or to nothing if you use -b), and doesn't fetch anything. Whatever is causing your slowness, it's something else.