On Wed, Jun 8, 2016 at 11:19 PM, Jeff King <peff@xxxxxxxx> wrote: > 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@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html