Git Objects: per-object commit history

[jbenet]

Git's object model has one commit tree history per repository. Commits point to commits and trees. Trees cannot point to commits. (See discussion on alternative here: #4 )

One thing that svn had over git ("svn had something over git? you're crazy.") is transparent subtree versioning. Each directory versioned itself. This was notoriously annoying as every directory had its own .svn directory, polluting your entire file system. Super annoying. BUT it was useful. In that model -- if svn hadn't made other design mistakes -- you could conceive of mixing subtrees between repositories seamlessly. E.g.

I'm talking about having the same subdirectory be within two different repos:

./
└── my_repo_a/
│        └── subtree_foo/
└── my_repo_b/
         └── subtree_foo/

"Oh, that's a submodule!" Sure. In git-land, it's a submodule. And (also notoriously) annoying to work with. I don't want to manage an entire repo for this shared subtree. I want a cheap submodule. Git already does cheap branching. I want cheap repos.

This is easy to do if every object has (or can have) its own commit history. (and commits can be embedded into trees. See #4). this can be really annoying to manage/manipulate manually. But it could be done automatically for you really nicely. Without littering .<vcs> everywhere.

This will be a feature of IPFS.

[jbenet]

Applications this would be really nice for:

• Shared docs (google docs like thing)
• A legal document repository, where each document (a) has its own version history, (b) can be forked independently, (c) can be included independently. (Say juan.benet.ai/paperwork/w4 is a fork of irs.us.gov/forms/w4).