Re: [PATCH 2/2] fetch-pack: respect --no-update-shallow in v2

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 26, 2019, 15:39 UTC
Message-ID: <CACsJy8A5F5Cj02ViO31oFHzOPrdUr+=Gp1q1BEXz7kHDkZTz3A@mail.gmail.com>
In-Reply-To: <20190326151825.GA26167@sigill.intra.peff.net>

On Tue, Mar 26, 2019 at 10:18 PM Jeff King <peff@peff.net> wrote:

Show 19 quoted lines

>
> 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