Pijul

Pijul is a distributed version control system written in Rust that uses a patch-based theoretical model instead of the snapshot-based model used by Git. Where Git tracks the state of files at each commit, Pijul tracks the changes (patches) themselves as the fundamental unit — and because patches are independent, commutative objects, the order in which you apply them does not matter. This property eliminates entire classes of merge conflicts that Git users encounter regularly.

The core idea

In Git, a merge conflict arises when two branches have diverged in ways Git can't automatically reconcile. The result depends on the order of operations — rebasing A onto B can produce a different result than rebasing B onto A, even when both should be logically equivalent.

Pijul's model is based on a sound mathematical theory (closely related to CRDTs) in which patches are designed to be commutative — applying patch A then B yields the same result as applying B then A. This means:

• Rebasing is always clean when there are no genuine semantic conflicts
• Cherry-picking works without accumulating phantom conflicts
• The history is a true partial order of changes, not a linear narrative

Features

• Conflict-free merges — conflicts only arise when two patches make genuinely incompatible changes to the same lines; order-of-application conflicts don't exist
• Distributed — fully decentralised like Git; clone, push, and pull between any peers
• The Nest — the official hosting platform at nest.pijul.com, analogous to GitHub for Pijul repositories
• SSH and HTTP transport — push and pull over SSH or HTTPS just like Git
• Interactive record — select individual hunks to include in a patch when recording, similar to git add -p
• Single Rust binary — one self-contained binary with no runtime dependencies
• Fast — written in Rust with performance as a priority

Installation

cargo install pijul

Or download a pre-built binary from pijul.org/download:

# Debian / Ubuntu
# An official .deb package is available on the
# [downloads page](https://pijul.org/download/).

# Fedora
dnf install pijul

# macOS
brew install pijul

# Arch Linux (AUR)
paru -S pijul

# Nix
nix-env -iA nixpkgs.pijul

Basic Usage

# Initialise a new repository
pijul init

# Check the current status
pijul diff

# Record a patch (interactively select hunks)
pijul record -m "add login page"

# Record all changes at once
pijul record -a -m "add login page"

# View the patch log
pijul log

# Clone a repository from the Nest
pijul clone https://nest.pijul.com/pijul/pijul

# Clone over SSH
pijul clone ssh://nest.pijul.com/your-username/your-repo

# Push to a remote
pijul push

# Pull from a remote
pijul pull

Channels

Pijul uses channels where Git uses branches. A channel is a set of applied patches:

# List channels
pijul channel

# Create a new channel
pijul channel new feature-login

# Switch to a channel
pijul channel switch feature-login

# Merge another channel into the current one
pijul merge main

Working with patches

Because patches are first-class objects, you can manipulate them directly:

# Show the changes in a specific patch
pijul diff --patch <patch-hash>

# Unrecord the most recent patch (keeps changes in the working tree)
pijul unrecord

# Apply a specific patch from another channel
pijul apply <patch-hash>

The Nest

Pijul's official hosting platform mirrors the basic GitHub workflow:

# Fork a project on the Nest, then:
pijul clone https://nest.pijul.com/your-username/forked-repo
# make changes
pijul record -m "fix: correct typo in README"
pijul push
# then open a patch request on the Nest UI

Comparison with Git

When to choose Pijul

Pijul is worth trying if you:

• Work in long-lived feature branches that regularly need to merge from main
• Frequently cherry-pick commits and end up with phantom conflicts
• Find Git's rebase model conceptually confusing
• Are curious about the theoretical foundations of version control

It is still less mature than Git in terms of ecosystem tooling (no equivalent of git bisect, fewer GUI integrations, smaller hosting ecosystem), but for day-to-day commit, push, pull, and merge workflows it is production-ready.