4 ms·

> Notably missing is support for merging, which ZFS does not have direct support for as far as I'm aware. So, no replacement. Merge and Branch are the major fe

by erikb 10y ago

> Notably missing is support for merging, which ZFS does not have direct support for as far as I'm aware. So, no replacement. Merge and Branch are the major features of git. The bigger the project the bigger the need for these. I know some projects where people work full time as merge conflict resolvers. Without git that would require a whole team instead of a person.

ChristianGeek 10y ago
"Of course, I'm not seriously suggesting you'd ditch a 'proper' version control system, but it gives a good sense of what's possible at the file system level."
- erikb 10y ago
  That's what the title says in big letters at the top though.
urubujj 10y ago
full time?? wow
- m45t3r 10y ago
  One unknown person called Linus Torvalds is one of them ;).
  - OJFord 10y ago
    And there was me thinking Mr Torvalds mostly provoked conflicts.. :p
    - erikb 10y ago
      Yes, and these can't be merged with git yet.
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 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 ago
    The 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. ;)

by erikb 10y ago

ChristianGeek 10y ago

"Of course, I'm not seriously suggesting you'd ditch a 'proper' version control system, but it gives a good sense of what's possible at the file system level."

erikb 10y ago
That's what the title says in big letters at the top though.

urubujj 10y ago

full time?? wow

m45t3r 10y ago
One unknown person called Linus Torvalds is one of them ;).
- OJFord 10y ago
  And there was me thinking Mr Torvalds mostly provoked conflicts.. :p
  - erikb 10y ago
    Yes, and these can't be merged with git yet.

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 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 ago
  The 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. ;)