Re: Question about your git habits
- From
- J.C. Pizarro <jcpiza@gmail.com>
- Date
- Feb 23, 2008, 13:08 UTC
- Message-ID
- <998d0e4a0802230508w12f236baiaf2d9ab5f364670a@mail.gmail.com>
- In-Reply-To
- <20080223113952.GA4936@hashpling.org>
On 2008/2/23, Charles Bailey <charles@hashpling.org> wrote:
Show 27 quoted lines
> 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.