Derrick Stolee wrote: > Of course, with the speedups from reachability bitmaps, it is sometimes > _faster_ to do a partial clone than a shallow clone. (It definitely takes > less time in the "counting objects" phase, and the cost of downloading > all commits and trees might be small enough on top of the necessary blob > data to keep the total cost under a shallow clone. Your mileage may vary.) > Because the cost of a partial clone is "comparable" to shallow clone, I > would almost recommend partial clone over shallow clones 95% of the time, > even in scenarios like automated builds on cloud-hosted VMs. By the way, an idea for the interested (#leftoverbits?): It would be possible to emulate the shallow clone experience making use of the partial clone protocol. That is, fetch a full history without blobs but record the "shallows" somewhere and make user-facing traversals like "git log" stop there (similar to the effect "git replace" has on user-facing traversals). Then later fetches would be able to take advantage of the full commit history, but scripts and muscle memory (e.g., the assumption that most commands will never contact the remote) that assume a shallow clone would continue to work. Would that be useful or interesting to people? Thanks, Jonathan
