Re: Calculating tree nodes

Are tree objects really needed?

1) Make the path an attribute of the file object.
2) Commits are simply a list of all the objects that make up the commit.
Sort the SHAs in the commit and delta them.

This is something that has always bugged me about file systems. File systems force hierarchical naming due to their directory structure. There is no reason they have to work that way. Google is an example of a giant file system that works just fine without hierarchical directories. The full path should be just another attribute on the file. If you want a hierarchical index into the file system you can generate it by walking the files or using triggers. But you could also delete the hierarchical directory and replace it with something else like a full text index. Directories would become a computationally generated cache, not a critical part of the file system. But this is a git list so I shouldn't go too far off into file system design.

Git has picked up the hierarchical storage scheme since it was built on a hierarchical file system. I don't this this is necessarily a good thing moving forward.

If we really need tree objects they could become a new class of computationally generated objects that could be deleted out of the database at any time and recreated. For example if you think of the file objects as being in a table, inserting a new row into this table would compute new tree objects (an index).

Index is the key here, we may want other kinds of indexes in the future. It was the mail about auto-generating the Maintainers list that caused me to think about this. If file objects are a table with triggers, building a hierarchical index for the Maintainers field doesn't make sense.

These are just some initial thoughts on a different way to view the data git is storing. Thinking about it as a database with fields and indexes built via triggers may change the way we want to structure things.