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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html