politics: delete references to Pijul

README.md

@@ -58,13 +58,12 @@ systems into a single tool. Some of those sources of inspiration include:
   powerful and simple. Formatting output is done with a robust template language
   that can be configured by the user.
 
-- **Pijul & Darcs**: Jujutsu keeps track of conflicts as [first-class
+- **Darcs**: Jujutsu keeps track of conflicts as [first-class
   objects][conflicts] in its model; they are first-class in the same way commits
   are, while alternatives like Git simply think of conflicts as textual diffs.
-  While not as rigorous as systems like Darcs and Pijul (which are based on a
-  formalized theory of patches, as opposed to snapshots), the effect is that
-  many forms of conflict resolution can be performed and propagated
-  automatically.
+  While not as rigorous as systems like Darcs (which is based on a formalized
+  theory of patches, as opposed to snapshots), the effect is that many forms of
+  conflict resolution can be performed and propagated automatically.
 
 [perf]: https://github.com/martinvonz/jj/discussions/49
 [revset]: https://martinvonz.github.io/jj/latest/revsets/

docs/conflicts.md

@@ -3,14 +3,13 @@
 
 ## Introduction
 
-Like [Pijul](https://pijul.org/) and [Darcs](http://darcs.net/) but unlike most
-other VCSs, Jujutsu can record conflicted states in commits. For example, if you
-rebase a commit and it results in a conflict, the conflict will be recorded in
-the rebased commit and the rebase operation will succeed. You can then resolve
-the conflict whenever you want. Conflicted states can be further rebased,
-merged, or backed out. Note that what's stored in the commit is a logical
-representation of the conflict, not conflict *markers*; rebasing a conflict
-doesn't result in a nested conflict markers (see
+Unlike most other VCSs, Jujutsu can record conflicted states in commits. For
+example, if you rebase a commit and it results in a conflict, the conflict will
+be recorded in the rebased commit and the rebase operation will succeed. You can
+then resolve the conflict whenever you want. Conflicted states can be further
+rebased, merged, or backed out. Note that what's stored in the commit is a
+logical representation of the conflict, not conflict *markers*; rebasing a
+conflict doesn't result in a nested conflict markers (see
 [technical doc](technical/conflicts.md) for how this works).
 
 

docs/related-work.md

@@ -18,8 +18,6 @@ Similar tools:
   interface for Git. Like Jujutsu, does not have an "index"/"staging area"
   concept. Also doesn't move the working-copy changes between branches (which
   we do simply as a consequence of making the working copy a commit).
-* [Pijul](https://pijul.org/): Architecturally quite different from Jujutsu,
-  but its "first-class conflicts" feature seems quite similar to ours.
 * [Breezy](https://www.breezy-vcs.org/): Another VCS that's similar in that it
   has multiple storage backends, including its own format as well as .git
   support.

lib/src/merge.rs

@@ -92,8 +92,8 @@ where
     } else if counts.len() == 2 {
         // All sides made the same change.
         // This matches what Git and Mercurial do (in the 3-way case at least), but not
-        // what Darcs and Pijul do. It means that repeated 3-way merging of multiple
-        // trees may give different results depending on the order of merging.
+        // what Darcs does. It means that repeated 3-way merging of multiple trees may
+        // give different results depending on the order of merging.
         // TODO: Consider removing this special case, making the algorithm more strict,
         // and maybe add a more lenient version that is used when the user explicitly
         // asks for conflict resolution.