Why not Git

[hack3ric]

Just curious. My current agent sandbox is bubblewrap with .git bind mount read-only. I think Git covers most of the usage you mentioned, and without FUSE overhead in every I/O operation. So are there justifications why we need this in the lower level rather than just VCS?

[congwang-mk]

Hi @hack3ric,

1. git version-controls source code, not other files like artifacts of a package installation. IOW, not the entire filesystem
2. even with git worktree, there is no isolation enforced, that is, one agent could delete all the branches/worktrees which other agents may still work on.
3. branchfs intentionally avoids merge by design, because solving merge conflicts is not trivial hence not easy to automate.

[hack3ric]

Hi,

1. Git can version control binaries. And if you don't want to destroy the current Git repo structure that the source code agents are working on currently has, you can use git --git-dir=/path to specify another Git structure to provide another set of history. You can then overlay .gitignore with an empty file to include everything.

2. With sandbox like bubblewrap, you can enforce isolation by bind-mounting .git as read-only (as previously stated). If agents need to control work tree, you can probably work around the sandbox and expose a subset of git worktree command via IPC.

3. I think your first commit wins strategy can be achieved by git update-ref <new> <old>, as it's basically a CAS against references.

I don't think this is specifically clean if laid out like this without a wrapper, but this does not justify a brand new filesystem implementation for me. Is there anything missing in Git (plus the usage of sandbox, which we probably should in LLM agent contexts) that we really need filesystem-level abstraction?