3 ms·
That is a very interesting idea, imo. I don't really like the object storage backend. E.g., I'm not sure if it's really the smartest to split the hash into dire
by erikb 10y ago
That is a very interesting idea, imo. I don't really like the object storage backend. E.g., I'm not sure if it's really the smartest to split the hash into directories and filenames. And the whole idea of tree files seems flawed (you don't need them if you consider the (checked out) file path as part of the file name and have that completely in commit files as if they would be a single global tree file).
- cyphar 10y agoThe object store is done in the way it's done for two reasons. The first being that using individual files doesn't require opening some database file to parse the state of the repo -- and pushes and pulls are very simple to implement (you just download the objects to .git/objects and then update any refs in .git/refs). Secondly, the splitting of the filename into a directory is because filesystems have very bad performance when you put >500000 files in one directory. Remember that git was created to deal with the Linux kernel source, so they have very large numbers of git objects and operations need to be fast. I actually think the git object store is very clever. ;)