On Tue, Mar 26, 2019 at 10:18 PM Jeff King <p...@peff.net> wrote: > > On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote: > > > > That seems like the best we can do without the protocol change. And even > > > if we adjust the protocol, we need some fallback behavior for existing > > > v2 servers, so this is worth doing. > > > > Are people actually doing this (i.e. cloning from or pushing to a > > shallow repo)? I added this with the intention that a big shallow repo > > (e.g. one year long history) is served as the common source to reduce > > server loads and everything, while the full/big repo is available but > > rarely needed. I never saw anyone complain about it (so, likely not > > using it). > > I don't think I've ever seen anybody serve fetches out of a shallow > clone in practice (I don't think we ever seriously considered them at > GitHub, but given their general incompatibility with reachability > bitmaps, I suspect it would cause more performance problems than it > solves).
Yeah. I still think it scales better long term because you can control this history depth in the common case instead of trying to make git work well with 30+ years worth of commits. I might try to make reachability bitmaps and commit-graph work with shallow clones one day, but that's pretty much in the "hey this is fun, are you bored?" category. > I've always imagined people do it for one-offs. E.g., they have a > shallow clone, and fetch out of that to a temporary copy. That may be > less useful these days with the advent of separate worktrees. -- Duy
