From: J.C. Pizarro Date: Sat, 23 Feb 2008 13:08:35 GMT Subject: Re: Question about your git habits Message-ID: <998d0e4a0802230508w12f236baiaf2d9ab5f364670a@mail.gmail.com> In-Reply-To: <20080223113952.GA4936@hashpling.org> On 2008/2/23, Charles Bailey 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.