Re-fetching a remote after deletion can be slow

[mattmccutchen]

#47 introduced a performance problem: re-fetching a remote from the cache after deleting and re-adding it can take a nontrivial amount of time even if all the objects are still present in the repository. For example, re-fetching a mirror of a subdirectory of DefinitelyTyped takes 10 seconds on my laptop. It looks like git fetch validates twice(!) that the receiving repository contains all objects that are transitively referenced by the refs being fetched but not by the refs already in the receiving repository (first time, second time), and each scan takes 5 seconds in my example. I haven't researched why git does this.

Depending on how severely the problem affects common Braid use cases (see #69), we should consider asking for a way to alter git's behavior or implementing a better workaround in Braid than manually passing --keep to every command. I have a bunch of ideas that I can write up if it becomes relevant.

[mattmccutchen]

Some time ago, I had the idea that we can completely avoid fetching from the cache to the downstream repo (which wastes a lot of disk space in addition to being slow) by preparing the commit for braid update or whatever in a temporary repository with both the cache and the downstream repo as alternates and fetching it from there to the downstream repository, like we do for braid push. Unfortunately, it may require significant surgery to make all the relevant Braid commands go through this flow. I'll add it to my long to-do list.