On Thu, Jun 09, 2016 at 03:53:26PM +0700, Duy Nguyen wrote: > > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
