The three high-level features of Jujube are described as:
The working copy is a commit - All runs of the tool log/commit the current state of edits
Commits can contains conflicts - Conflicts are folded back into the repository
Operations are logged
One of the things I love (and hate š) about git is how it reflects just the DAG of changes.
Iām super curious how folding in the management of conflicts into repositories would impact other areas of tooling / workflows.
It seems to me that including conflicts as a first-class repository entity would reflect the DAG of changes even better, and allow much more interesting / helpful tooling.
To quote the authorās description of commits containing conflicts:
It means that there is a consistent way of resolving conflicts: check out a commit with conflicts in, resolve the conflicts, and amend them into the conflicted commit. Then evolve descendant commits.
It naturally enables collaborative conflict resolution.
The in-tree conflicts means that there is no need for book-keeping in rebase-like commands to support continue/abort operations. Instead, the rebase can simply continue and create the desired new DAG shape.
One of the interesting aspects here is a bit hidden as supporting āEvolutionā. It tracks the meta changes of a repository. How commits moved, e.g. if you have two commits squashed together, there will be an edge from the two original commits to the squashed commits, so you can trace this back. Same applies to rebases, etc. So you reflect not just the history as an engineer wants it, but also how it originated.
The three high-level features of Jujube are described as:
One of the things I love (and hate š) about git is how it reflects just the DAG of changes.
Iām super curious how folding in the management of conflicts into repositories would impact other areas of tooling / workflows.
It seems to me that including conflicts as a first-class repository entity would reflect the DAG of changes even better, and allow much more interesting / helpful tooling.
To quote the authorās description of commits containing conflicts:
One of the interesting aspects here is a bit hidden as supporting āEvolutionā. It tracks the meta changes of a repository. How commits moved, e.g. if you have two commits squashed together, there will be an edge from the two original commits to the squashed commits, so you can trace this back. Same applies to rebases, etc. So you reflect not just the history as an engineer wants it, but also how it originated.