2 ms·
ZFS could not be a replacement for all of git, but (if you wanted to) you could use it to replace git's storage layer, which is basically independent of operati
by firethief 10y ago
ZFS could not be a replacement for all of git, but (if you wanted to) you could use it to replace git's storage layer, which is basically independent of operations like merge. I.e. you can git-merge ZFS subvolumes (without any actual git repos) with recursive git-merge-file.
- erikb 10y agoThat 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. ;)