Re: Distribution of longest common hash prefixes

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 4 Apr 2007, Olivier Galibert wrote:
> 
> Isn't the number of objects an order of magnitude bigger than the
> number of commits?  Well, I guess that depends on your workflow...

Judging by the kernel tree, it's not an order of magnitude, although it's 
fairly close:

	[torvalds@woody linux]$ git rev-list --all | wc -l
	51156

	[torvalds@woody linux]$ git rev-list --all --objects | wc -l
	444265

So you have about 50k commit objects, and about 390k "other" objects. 
About 7.7 "other" objects per commit. Not quite an order-of-magnitude, but 
close.

Part of the reason for this is that the kernel people tend to encourage 
lots of smaller commits over single large commits, so we have lots of 
commits.

To counter-act that somewhat, the kernel tree is also pretty deep, so a 
lot of the "other" objects are actually the tree objects that create the 
directory structure - it's quite normal to have a single file (blob) 
change, and then three new trees that lead up to that file, and the one 
commit that explains it.

Other projects - like git itself - have relatively fewer tree objects, 
which is probably why the ratio for git itself is just 3.04 "other" 
objects for each commit (ie on average, commits probably touch two blobs 
and the top-level tree - about 10 commits, and 30k non-commit objects).

So repo layout matters. Iirc, last I did the statistics, the git 
repository had more blobs than trees, while the kernel repo had more trees 
than blobs. And the commits-to-other-objects is obviously fairly different 
as a result (I think both git and the kernel have the "many small changes" 
approach, so they're similar in that respect).

Other repositories probably have more "big changes". Especially if you 
create the repo initially by importing just big releases over time, you'll 
have relatively few commits, and lots of blob/tree changes. 

			Linus