politics: delete references to Pijul

The Pijul maintainer has opinions that I don't understand about how we
mention Pijul (they consider the current mentions offensive as
"bashing Pijul"). Let's just remove the references so we don't have to
deal with it. I think the references to Darcs we already had in most
of these places are sufficient.
This commit is contained in:
Martin von Zweigbergk 2024-04-14 06:57:20 -07:00 committed by Martin von Zweigbergk
parent aaa2025dfc
commit 0525dc9d86
4 changed files with 13 additions and 17 deletions

View file

@ -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/

View file

@ -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).

View file

@ -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.

View file

@ -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.