On 2008/2/23, Charles Bailey <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 03:47:07AM +0100, J.C. Pizarro wrote: > > > > Yesterday, i had git cloned git://foo.com/bar.git ( 777 MiB ) > > Today, i've git cloned git://foo.com/bar.git ( 779 MiB ) > > > > Both repos are different binaries , and i used 777 MiB + 779 MiB = 1556 > MiB > > of bandwidth in two days. It's much! > > > > Why don't we implement "binary delta between old git repo and recent git > repo" > > with "SHA1 built git repo verifier"? > > > > Suppose the size cost of this binary delta is e.g. around 52 MiB instead > of > > 2 MiB due to numerous mismatching of binary parts, then the bandwidth > > in two days will be 777 MiB + 52 MiB = 829 MiB instead of 1556 MiB. > > > > Unfortunately, this "binary delta of repos" is not implemented yet :| > > > It sounds like what concerns you is the bandwith to git://foo.bar. If > you are cloning the first repository to somewhere were the first > clone is accessible and bandwidth between the clones is not an issue, > then you should be able to use the --reference parameter to git clone > to just fetch the missing ~2 MiB from foo.bar. > > A "binary delta of repos" should just be an 'incremental' pack file > and the git protocol should support generating an appropriate one. I'm > not quite sure what "not implemented yet" feature you are looking for.
But if the repos are aggressively repacked then the bit to bit differences are not ~2 MiB. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
