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

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 9, 2016, 08:53 UTC
Message-ID: <CACsJy8BGV-AWwap9c2hOjXWMYxBLUirX8i20rS_=Vmci_SG_rw@mail.gmail.com>
In-Reply-To: <20160608161958.GA30876@sigill.intra.peff.net>

On Wed, Jun 8, 2016 at 11:19 PM, Jeff King <peff@peff.net> wrote:

Show 15 quoted lines

> On Wed, Jun 08, 2016 at 05:44:06PM +0700, Duy Nguyen wrote:
>
>> On Wed, Jun 8, 2016 at 3:23 AM, Jeff King <peff@peff.net> wrote:
>> > Because this "external odb" essentially acts as a git alternate, we
>> > would hit it only when we couldn't find an object through regular means.
>> > Git would then make the object available in the usual on-disk format
>> > (probably as a loose object).
>>
>> This means git-gc (and all things that do rev-list --objects --all)
>> would download at least all trees and commits? Or will we have special
>> treatment for those commands?
>
> 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!

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

-- 
Duy