Re: [RFC] Speeding up a null fetch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 11, 2007, 23:49 UTC
Message-ID: <Pine.LNX.4.63.0702120045320.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <200702112332.14698.julian@quantumfyre.co.uk>

Hi,

On Sun, 11 Feb 2007, Julian Phillips wrote:

Show 5 quoted lines

> An artifical test repository that has similar features (~25000 commits,
> ~8000 tags, ~900 branches and a 2.5Gb packfile) when running locally
> takes ~20m to clone and ~48m to fetch (with no new commits in the
> original repository - i.e. the fetch does not update anything) with a
> current code base (i.e. newer than 1.5.0-rc4).

Ouch.

I hope you packed the refs?

BTW your patch
- was not minimal (and therefore it takes longer than necessary to find 
  what you actually fixed),
- it does not show where and how the call to show-ref is avoided (I 
  eventually understand that you avoid calling update_local_ref early, but 
  you sure could have made that easier), and
- it uses Pythong.

Also, it touches a quite core part of git, which will hopefully be replaced by a builtin _after_ 1.5.0.

> However, this seems more band-aid than fix, and I wondered if someone 
> more familiar with the git internals could point me in the right 
> direction for a better fix, e.g. should I look at rewriting fetch in C?

Look into the "pu" branch of git. There are the beginnings of a builtin (written in C) fetch.

But this _will_ have to wait until after 1.5.0.

Ciao, Dscho