I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git’s data model. A data-first approach with blob, tree, commit, and tag can be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.
I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git’s data model. A data-first approach with
blob,tree,commit, andtagcan be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.