Now that we can put the "from" and "to" sides on separate lines, we can
use the normal "(no terminating newline)" comment on each side
separately. This should also be more clear, since previously the
"(no terminating newline)" comment could possibly be confused for
"(removes terminating newline)".
Before:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base"
\\\\\\\ to: ysrnknol 7a20f389 "commit B" (adds terminating newline)
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
After:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base" (no terminating newline)
\\\\\\\ to: ysrnknol 7a20f389 "commit B"
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
An example with parents `rtsqusxu` and `ysrnknol`:
```
<<<<<<< conflict 1 of 1
%%%%%%% diff from: vpxusssl 38d49363 "description of base"
\\\\\\\ to: rtsqusxu 2768b0b9 "description of left"
-base
+left
+++++++ ysrnknol 7a20f389 "description of right"
right
>>>>>>> conflict 1 of 1 ends
```
Conflict labels will generally start with lowercase change IDs, so
making all of the text lowercase makes it more consistent. I also
removed the "contents of" text, since conflict labels will already be
long enough, and this text doesn't add anything. Similarly, I removed
the "(conflict 1 of 1)" note from the Git conflict markers since Git
doesn't include this information, and including it would result in extra
long lines once we add conflict labels.
The current comment uses `[noeol]`, which can be difficult to
understand. In this commit, the brackets are changed to parentheses to
make it clear that there is no semantic meaning to the comment, and the
wording is changed to be more clear to the user.
The meaning of `[noeol]` might not be immediately clear to a user, so it
would be good to document it on our documentation page for conflicts. We
may also want to improve the conflict marker comments we use for this
case in the future (possibly after receiving user feedback).
The current docs for conflict markers start out by introducing Git
"diff3" conflict markers, and then discussing how Jujutsu's conflict
markers are different from Git's. I don't think this is the best way to
explain it, because it requires the reader to first understand Git's
conflict markers before they go on to learn Jujutsu's conflict markers.
Instead, I think it's better to explain the conflict markers from
scratch with a more detailed example so that we don't assume any
particular knowledge of Git.
This structure also works better with the new config option, since we
can talk about the default option first, and then go on to explain
alternatives later.
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.
When importing `conflicts.md` into the Google repo, our internal tools
complained that it contained conflict markers. Similarly, if you ever
get an actual merge conflict in the file, the working-copy
snapshotting would parse our sample conflict markers here, forcing you
to work around it. Let's avoid that by indenting the conflict
markers. Hopefully readers will understand that the leading space is
not part of the markers.
I feel the original -------/+++++++ pair is slightly confusing because
each half can be a separator by itself. I don't know what character other
than '-'/'+' is preferred, but let's pick '%' (for "mod") per @martinvonz
suggestion.
We used to have documention about how conflicts are implemented, but I
removed that a long time ago when I rewrote the README to target users
rather than VCS hackers. Let's have a doc for the VCS hackers (and
curious users) as well, though.
