Add ability to pre-cache common UI operations that result in "git" commands
I had a comment on another issue that started describing one aspect of this, which resulted in some narrow caching solution (not pre-caching) and that ticket got closed.
On big monorepos all sorts of operations in the UI will execute long-running "git" commands. E.g. the git rev-list --max-count=1 <rev> -- <file>
mentioned in the linked comment above, history view, blame etc.
Just caching this on a big repo with a huge update rate doesn't do much, the cache gets busted almost immediately, and it doesn't help the first (and likely only) person viewing the landing page for a repo that'll wait on the cache propagation.
So it would be great to have some option to trade CPU / IO / capacity on some backend system for a responsive UI. As soon as a ref is pushed, some job kicks off and starts populating all this (down to perhaps updating history for all files changed since last time). Then by the time someone clicks "history", "blame" etc. it's populated and renders almost instantly.
This would be very useful on big monorepos where these operations in the UI are slow.