Re: [PATCH v3 3/4] gitfaq: shallow cloning a repository

[Jonathan Nieder <jrnieder@gmail.com>]

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