As per what we observed in getCommits data set in Honeycomb, most of the GraphQL queries using the gitCommitResolver, either directly or indirectly, don't ask for information beyond the commit ID or URL, which can be constructed statically without calling out to git-server to run an expensive git log operation.
This change also makes it so the above code paths don't trigger any lazy adding of repos that are being seen for the first time, which on sourcegraph.com wasn't happening anyways, and on customer instances isn't needed, since we know the repos we have at hand already do exist in the repo table.
This doesn't change the behaviour of ensuring a revision exists when running a git command (like git log).
These are client calls that should see speed improvements from having at least -1 RPCs to gitserver:
These code paths are so pervasive, that this should result in a slight to significant (depending on the specific client call) performance improvement across the whole product. We'll be able to monitor the performance of these GraphQL queries with the internal dashboard checked-in with this PR (cc @bobheadxi @pecigonzalo).
