Re: [PATCH v2] git-rebase.txt: use back-ticks consistently

[Derrick Stolee <derrickstolee@github.com>]

On 6/28/22 5:49 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> -apply backend: When applying a patch, ignore changes in whitespace in
>> -context lines. Unfortunately, this means that if the "old" lines being
>> -replaced by the patch differ only in whitespace from the existing
>> -file, you will get a merge conflict instead of a successful patch
>> -application.
>> +apply backend:;;
> 
> Hmph, I am surprised that you took this, with an extra colon.  Does
> it format nicely?

Well, this is somewhat of an "oops" because I honestly thought you
had kept the colons in your comment, but it turns out that I misread
it.

I had replied with this doc-diff:

-           apply backend: When applying a patch, ignore changes in whitespace
-           in context lines. Unfortunately, this means that if the "old" lines
-           being replaced by the patch differ only in whitespace from the
-           existing file, you will get a merge conflict instead of a
-           successful patch application.
+           apply backend:
+               When applying a patch, ignore changes in whitespace in context
+               lines. Unfortunately, this means that if the "old" lines being
+               replaced by the patch differ only in whitespace from the
+               existing file, you will get a merge conflict instead of a
+               successful patch application.
 
-           merge backend: Treat lines with only whitespace changes as
-           unchanged when merging. Unfortunately, this means that any patch
-           hunks that were intended to modify whitespace and nothing else will
-           be dropped, even if the other side had no changes that conflicted.
+           merge backend:
+               Treat lines with only whitespace changes as unchanged when
+               merging. Unfortunately, this means that any patch hunks that
+               were intended to modify whitespace and nothing else will be
+               dropped, even if the other side had no changes that conflicted.

So, we do have a render that doesn't look awful, but since we already
have formatting that makes it clear these are subsections, the colons
are not needed.

Thanks,
-Stolee