Re: [QUESTION] about .git/info/grafts file

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 19, 2006, 16:58 UTC
Message-ID: <Pine.LNX.4.64.0601190842270.3240@g5.osdl.org>
In-Reply-To: <20060119130940.GC28365@pasky.or.cz>

On Thu, 19 Jan 2006, Petr Baudis wrote:

Show 8 quoted lines

>
> Dear diary, on Thu, Jan 19, 2006 at 11:51:22AM CET, I got a letter
> where Franck <vagabon.xyz@gmail.com> said that...
> > well, dealing with a repo that has more than 300,000 objects becomes a
> > burden. A lots of git commands are slow, and cloning it take a while !
> 
> Were the objects packed? It would be interesting to have some data about
> how GIT performs with that much objects...

The historical linux archive has a lot more than 300,000 objects. In fact, even the _current_ kernel archive has almost 200,000 objects.

Maybe somebody was thinking "commits", not "objects". Something with 300,000 commits is indeed a pretty big project.

Anyway, from a scalability standpoint, git should have no problem at all with tons of objects, as long as you pack the old history. There are a few things that get slower:

 - if you end up doing things that look at history, they are obviously at 
   least linear is history size. Often there are other downsides too 
   (using lots of memory).

   Example: try even just a simple "gitk" on the (regular, new) kernel 
   archive, and it will take a while before the whole thing has been done. 
   Of course, you'll see the top entries interactively, so mostly you 
   won't care, but I routinely limit it some way just to make it not make 
   the CPU fans come on. So I do something like

	gitk --since=1.week.ago
	gitk v2.6.15..

   instead of plain gitk, just because it makes operations cheaper.

 - a full clone takes a long time. Git _could_ fairly easily have an 
   extension to add a date specifier to clone too:

	git clone --since=1.month.ago <source> <dst>

   and just leave any older stuff (you could always fetch it later), but 
   we've just never done it. Maybe we should. It _should_ be pretty simple 
   to do from a conceptual standpoint.

but "everyday" operations shouldn't slow down from having a long history. I can still apply 4-5 patches a second to the kernel archive, for example, as you can see from

	git log --pretty=fuller | grep CommitDate | less -S

and looking for one of the patch series I've applied from Andrew..

		Linus