Prism VCS

Distributed version control through a clearer lens. A new VCS that builds on the good ideas of git, fossil, subversion, and mercurial, while simplifying the UI, and introducing unique concepts to Distributed VCSs.

Latest Commits

Prism

Prism is a new DVCS that takes ideas from git, mercurial, monotone, and fossil. It uses SHA3 by default, places a larger emphasis on worktrees, uses the "main" branch by default on init, introduces issue tracking as integrated into the repository, and has an easier stashing mechanism than git.

Worktrees

Prism places a much larger emphasis on worktrees. By default, when you create a new repository or clone a repository, Prism will set up your project directory with a `.prism` folder and a subdirectory for the main worktree.

You can add and remove as many worktrees as you want, and each worktree may checkout any branch, commit, or reference. Each worktree has its own head and staging index.

If you have two worktrees that are on the same branch and they both commit, much like Mercurial, you will end up with multiple heads on that branch.

Staging Area

Like Git, Prism uses a staging area to allow you to select which changes you want included in your next commit.

If you have staged a file and then change your mind, you can `prism unstage` a file so that it will no longer be included. This does not delete or reverse any changes to the file in the working directory.

Lineages

Prism also introduces new terminology for a concept that is sometimes used in git, but doesn't have its own name: collections of branches that have their own separate (parallel) histories.

In git, you can create an orphaned branch that begins with its own initial root commit and a clean history. It does not fork off from any other branch, and so its first commit does not have a parent.

This idea is used in git in a couple of different ways:

• GitHub Pages can use their own special orphaned branch with their own history.
• Wikis that have a special orphaned branch in which you want to separate its history from the history of the main project.
• A todo list, again, with a history separated from the main project.
• A complete rewrite of a project in which you want to start from a clean slate, with a completely clean history.
• Combining a separate project into another project, especially if the separate project was originally closed-source but has gotten to an open-source state.

Prism calls these *lineages*. Upon a repository initialization, a main lineage is created with a `main` branch. If you wanted to create a separate clean-slate history away from the main project, in git you would create an orphaned branch, but in Prism, you would create a new *lineage* with the following command:

prism lineage create [lineage_name]

A lineage begins with its own primary branch named after the lineage name. The first lineage upon repo initialization is named `main`, so the default (primary) branch it starts with is also named `main`. If you were to create the lineage `wiki`, its primary branch will be named `wiki`.

You can see a list of lineages with the following command:

prism lineage list

A lineage in Prism is really just a symbolic reference to its primary branch. Another way to think of lineages is that they are the *opposite* of forks. Where a fork separates off, a lineage starts already separated.

You can merge a lineage into another lineage by merging its primary branch into a branch of another lineage. The branch merged into becomes the branch the lineage now points to. This means a branch can be part of multiple lineages. Once the merge happens, the lineage can be dropped if one chooses.

Note that a repository must always have one main lineage. You cannot drop every lineage within a repository.

[TODO] You can turn a fork into its own lineage by giving it a new lineage name and dropping its past history.

TODO

• Subdirectories

- in index

- stage them

- commits

• File deletion
• When a file is staged and then deleted or moved, take that into account
• Figure out when files have been moved
• Diffs (myers, patience, and others)

- Binary diffing

• 3-way merge
• Allow multiple authors, signatures, committers in a commit object

- gpgsign sections

- SSH key signatures

• Prism repository configuration in its own orphaned branch so that it's versioned

- How would merge conflicts work for simple config values? Instead of editing a text file for conflicts, just prompt the user to fix the conflict interactively?

- Excludes would be an example of configuration that could use this system effectively.

• New property (or prop) object type that links to a tree or blob. It is a singular key-value store intended as a property to that file/directory.

- Inspired by subversion

- Properties on the root directory could be used for configuration on a specific versioning history (meaning, branches that don't stem from each other, like orphaned branches, have separate versioning histories, and therefore separate configurations).

- propedit, propset, proplist, propdel

- Property changes should show in diffs (and status)

- Propset file that lists all of the prop files

• Store versioned build artifacts in a separate space from the main lineage of commits.
• Ability to use Prism as a centralized VCS.

License

The main.go file is licensed under MPL 2.0, Incompatible with Secondary Licenses. All other files are licensed under BSD-3-Clause, unless noted otherwise within the file.