summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Bracht Laumann Jespersen <t@laumann.xyz>2022-09-28 23:51:55 +0200
committerThomas Bracht Laumann Jespersen <t@laumann.xyz>2022-09-28 23:51:55 +0200
commit54fc64cad9ca8f115e95eca48c8a059df0812f57 (patch)
tree46c88c6ea147c02fda8661e03c526cb95b1c709b
parent7573a55640e11ba960f0f4f9e2a0e2f02232b5c8 (diff)
ani/goodbadmerge: rework text
-rw-r--r--site/ani/goodbadmerge.md75
1 files changed, 46 insertions, 29 deletions
diff --git a/site/ani/goodbadmerge.md b/site/ani/goodbadmerge.md
index b5f1d10..b2e1495 100644
--- a/site/ani/goodbadmerge.md
+++ b/site/ani/goodbadmerge.md
@@ -22,6 +22,9 @@ immediately infer which should come before the other.
This is something that's been worked on extensively in Darcs.
+Here I want to retrace an existing demonstration of the "bad merge" and perform
+the equivalent steps with Pijul side-by-side and look at the end result.
+
<div id="goodbadmerge-pane" style="display: flex; flex-direction: row">
<div id="goodbadmerge-git" style="display: inline-block; max-width: 50%">
@@ -146,16 +149,39 @@ Let's try the same sequence with Pijul.
</div>
</div>
-OK, we see that the X ended up in the top of the file. This outcome is not
-affected by the merge direction, so merging `c` into `b` is not different from
-merging `b` into `c` (although the output from "git merge" will look different).
+See the X towards the bottom of the file? Here's the diff:
-## Pijul
+ $ diff -Naur merge-git/file.txt merge-pijul/file.txt
+ --- merge-git/file.txt 2022-08-04 12:09:49.054364728 +0200
+ +++ merge-pijul/file.txt 2022-08-04 11:56:16.251548521 +0200
+ @@ -1,6 +1,6 @@
+ A
+ B
+ -X
+ +C
+ D
+ E
+ G
+ @@ -8,6 +8,6 @@
+ G
+ A
+ B
+ -C
+ +X
+ D
+ E
+
+With Git, the X ended up towards the top of the file, but for Pijul it was able
+to track that the modification with X applied to the lines at the bottom. This
+outcome is not affected by the merge direction, so merging `c` into `b` is not
+different from merging `b` into `c` (although the output from "git merge" will
+look different).
-Let's try the same sequence with Pijul. The below sequence of commands is the
-same as we just did with Git, but all VCS-related commands have been switched
-from `git` to `pijul`. The following is a rough translation table:
+If you, like me, is a day-to-day Git user, I've written up a rough command
+translation table:
+
+<p>
<table>
<tr>
<td>
@@ -191,33 +217,24 @@ pijul log --channel bar (to find hashes to apply)<br/>
pijul apply hash
</td>
</table>
+</p>
-Pijul doesn't operate with **commits**, **branches**, and **merges**, instead
-the names are **changes** (or patches), **channels** and **apply**.
+Pijul doesn't operate with _commits_, _branches_, or _merges_, instead
+the terminology is _changes_ (or _patches_), _channels_ and _apply_. The
+implies in particular that you will never see something like a "merge
+conflict"—if the application of one change introduces a conflict, Pijul will
+warn about it just move on. The conflict is tracked internally, but it doesn't
+prevent you from applying or recording other unrelated changes.
+## References
-See the X towards the bottom of the file? Diffing the two resulting file
+ 1. [badmerge -- abstract version][badmerge-simple]
- $ diff -Naur merge-git/file.txt merge-pijul/file.txt
- --- merge-git/file.txt 2022-08-04 12:09:49.054364728 +0200
- +++ merge-pijul/file.txt 2022-08-04 11:56:16.251548521 +0200
- @@ -1,6 +1,6 @@
- A
- B
- -X
- +C
- D
- E
- G
- @@ -8,6 +8,6 @@
- G
- A
- B
- -C
- +X
- D
- E
+ 2. [badmerge -- concrete version with bad semantics](https://tahoe-lafs.org/~zooko/badmerge/concrete-bad-semantics.html)
+
+ 3. [Merging and patches][jneem-merging] on "A new version" blog
+ 4. [Merging, patches, and Pijul][jneem-pijul] on "A new version" blog
[Pijul]: https://pijul.org/
[catpatches]: https://arxiv.org/abs/1311.3903