A version control system is a piece of software that allows different authors to work collaboratively and asynchronously on a file, keeps track of their changes and alerts them when their edits are conflicting.

It can also be used by single authors to review and revert their changes. It is distinct from a parallel editor, in which all authors edit the same file concurrently.

There are basically two approaches to version control: snapshot-based (git, mercurial, svn) or patch-based (darcs). Historically, patch-based systems have been very simple to learn and use, but slow, whereas snapshot-based systems can be extremely fast, but are usually hard to use for more than simple operations.

Pijul combines these approaches, representing data in a more general way that allows efficient patch operations. Merges and conflicts are where this is most relevant.

Some things are really wrong, like using three-way merge for version control: there are real-world examples where Git, Mercurial and SVN just do the wrong thing.

Our experience with patch-based tools suggests this is possibly the simplest and most efficient way to control versions.

Thank you! We have an OpenCollective fund if you are interested in helping the project financially.

Pijul makes it easy to get only a subset of patches, and takes care of dependencies between patches to produce files consistent with a giant remote repository. If you are interested in trying it out for a large project, please contact us.

Pijul is the Mexican name of Crotophaga sulcirostris, a bird known for collaborative nest building.

It improves on darcs by speed and branch support. Compared to git/mercurial, the workflows are quite different:

• In Pijul, when you work with others, you often type commands such as "send my changes to others".
• In Git/Mercurial, the most common workflow is a "pull request", asking the system to compare versions and compute a "consistent" set of changes — where consistent is not what you think.

Yes. Pijul works in time logarithmic in the size of history for all non-conflicting patches (and almost all conflicting patches), and never exceeds linear time in conflicting cases.

The only caveat is that Pijul does not yet have an equivalent of darcs replace.

Since Pijul operates on patches rather than snapshots, versions are essentially unordered sets of patches. We solve the problem of communicating a specific version number by abusing elliptic curve cryptography primitives.

The license is GPL2, or any later version at your convenience. Pijul is free software and can be used freely to develop any kind of projects, including commercial ones.

If you are interested in using our base library, libpijul, in a project with a commercial license, please contact us.

Yes, but we don't have a good diff algorithm for them at the moment. Pijul could still perform reasonably well since you don't have to download intermediate versions of binary files to work with a repository.

In Git, cherry-picking takes some commits from another branch and rebases them onto the current branch, losing their identity. This causes artificial conflicts if you cherry-pick again between the same branches.

In Pijul, there are no "merge patches". Merging patches from a branch is equivalent to pulling from the branch. Cherry-picking works correctly and can be repeated without conflicts.