Re: [PATCH v2 4/4] bundle v3: the beginning

From: Jeff King <peff@peff.net>
Date: Jun 9, 2016, 17:23 UTC
Message-ID: <20160609172352.GC9016@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BGV-AWwap9c2hOjXWMYxBLUirX8i20rS_=Vmci_SG_rw@mail.gmail.com>

On Thu, Jun 09, 2016 at 03:53:26PM +0700, Duy Nguyen wrote:

Show 6 quoted lines

> > Yes. To me, this was always about punting large blobs from the clones.
> > Basically the way git-lfs and other tools work, but without munging your
> > history permanently.
> 
> Makes sense. If we keep all trees and commits locally, pack v4 still
> has a chance to rise!

Yeah, I don't think anything here precludes pack v4.

Show 10 quoted lines

> > I don't know if Christian had other cases in mind (like the many-files
> > case, which I think is better served by something like narrow clones).
> 
> Although for git-gc or git-fsck, I guess we need special support
> anyway not to download large blobs unnecessarily. Not sure if git-gc
> can already do that now. All I remember is git-repack can still be
> used to make a repo independent from odb alternates. We probably want
> to avoid that. git-fsck definitely should verify that large remote
> blobs are good without downloading them (a new "fsck" command to
> external odb, maybe).

I think git-gc should work out of the box; you'd want to use "repack -l", which git-gc passes already.

Fsck would be OK as long as you didn't actually load blobs. We have --connectivity-only for that, but of course it isn't the default. You'd probably want the default mode to fsck local blobs, but _not_ to fault in external blobs (but have an option to fault them all in if you really wanted to be sure you have everything).

-Peff