>In other words, each "commit" file is very small and cheap, but since >almost every commit will also imply a totally new tree-file, "git" is >going to have an overhead of half a megabyte per commit. Oops.>>Damn, that's painful. I suspect I will have to change the format somehow.

Having dodged that bullet with the change to make tree files point atother tree files ... here's another (potential) issue.

A changeset that touches just one file a few levels down from the topof the tree (say arch/i386/kernel/setup.c) will make six new files inthe git repository (one for the changeset, four tree files, and a newblob for the new version of the file). More complex changes make morefiles ... but say the average is ten new files per changeset since mostchanges touch few files. With 60,000 changesets in the current tree, wewill start out our git repository with about 600,000 files. Assumingthe first byte of the SHA1 hash is random, that means an average of 2343files in each of the objects/xx directories. Give it a few more years atthe current pace, and we'll have over 10,000 files per directory. Thissounds like a lot to me ... but perhaps filesystems now handle largedirectories enough better than they used to for this to not be a problem?