Re: git-fetching from a big repository is slow
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Dec 14, 2006, 14:14 UTC
- Message-ID
- <Pine.LNX.4.63.0612141513130.3635@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <4581573E.40803@op5.se>
Hi,
On Thu, 14 Dec 2006, Andreas Ericsson wrote:
Show 19 quoted lines
> Andy Parkins wrote: > > Hello, > > > > I've got a big repository. I've got two computers. One has the repository > > up-to-date (164M after repack); one is behind (30M ish). > > > > I used git-fetch to try and update; and the sync took HOURS. I zipped the > > .git directory and transferred that and it took about 15 minutes to > > transfer. > > > > Am I doing something wrong? The git-fetch was done with a git+ssh:// URL. > > The zip transfer with scp (so ssh shouldn't be a factor). > > > > This seems to happen if your repository consists of many large binary files, > especially many large binary files of several versions that do not deltify > well against each other. Perhaps it's worth adding gzip compression detecion > to git? I imagine more people than me are tracking gzipped/bzip2'ed content > that pretty much never deltifies well against anything else.
Or we add something like the heuristics we discovered in another thread, where rename detection (which is related to delta candidate searching) is not started if the sizes differ drastically.
Ciao, Dscho