On Sat, May 25, 2024 at 11:29:13AM +0100, Tom Hughes wrote: > > 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. > > This is true. One thing I found that makes things a lot more > efficient if you're using ssh as the transport is to enable > persistent multiplexing in .ssh/config with something like: > > Host git.example.com > ControlMaster auto > ControlPath /run/user/%i/ssh/control.%C > ControlPersist 1m > SendEnv GIT_PROTOCOL > > which avoids each fetch having to setup and authenticate a > new ssh session. Good point. That is sort of the opposite approach of my suggestion. That is, I was suggesting that git-blame batch everything to make a single efficient request. But if we could reduce the cost of making individual requests, then we wouldn't need to batch (which is quite a lot simpler). The ssh session is going to be one source of latency and overhead. But just spawning the fetch and remote upload-pack are another (especially if you have to authenticate, and especially with the v2 protocol, which has an extra round-trip for capabilities upgrade). If there was a long-running mode to git-fetch where it kept open a v2 session to the server and just said "hey, send me object X" and then "OK, now send me object Y" that would eliminate all of that overhead (and even for http, under the hood curl is good at keeping the session open between requests). You'd still have some extra latency (while you're talking to the server, the local blame process is paused), but I suspect it would be a lot more tolerable. And now your progress question is re-opened again. You might want a more succinct progress for something like blame that still does all of its fetching before generating output. E.g., you might want a single progress line with the current state (fetching or not), the count of fetched objects, the speed, and so on. And for something like "git log -p", where the progress would be interspersed with actual output, you might want to suppress it entirely. So yeah, I have no real objection to what your patch is doing. Depending on how future work unfolds it might be more or less useful than it is now, but even in the worst case it probably won't be a bad thing to have in our toolbox. -Peff
