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

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Stolee

On 27/06/2022 22:21, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <derrickstolee@github.com>
> 
> While inspecting the 'git rebase' documentation, I noticed that it is
> inconsistent with how it uses back-ticks (or other punctuation) for
> identifying Git commands, command-line arguments, or values for those
> arguments.
> 
> Sometimes, an argument (like '--interactive') would appear without any
> punctuation, causing the argument to not have any special formatting.
> Other times, arguments or 'git rebase' itself would have single-quotes
> giving a bold look (in the HTML documentation at least).
> 
> By consistently using back-ticks, these types of strings appear in a
> monospace font with special highlighting to appear more clearly as text
> that exists in a command-line invocation of a Git command.
> 
> This rather-large diff is the result of scanning git-rebase.txt and
> adding back-ticks as appropriate. Some are adding back-ticks where there
> was no punctuation. Others are replacing single quotes.
> 
> There are also a few minor cleanups in the process, such as one place
> that did not use tabs for the first paragraph in a bulletted list.
> Another case still referred to the dashed form, but it was the only use
> in the file except for the heading and NAME section.
> 
> Signed-off-by: Derrick Stolee <derrickstolee@github.com>

Thanks for doing this, I think it's fine as a single patch as all the 
changes are focussed making the quoting more consistent in a single file 
- splitting it up would be more work for you and would not really make 
it any easier for reviewers. I've left a few comments but it is a vast 
improvement as is.

> -The current branch is reset to <upstream>, or <newbase> if the
> ---onto option was supplied.  This has the exact same effect as
> -`git reset --hard <upstream>` (or <newbase>).  ORIG_HEAD is set
> +The current branch is reset to `<upstream>`, or `<newbase>` if the
> +`--onto` option was supplied.  This has the exact same effect as
> +`git reset --hard <upstream>` (or `<newbase>`). `ORIG_HEAD` is set

Unrelated to your change but I think we could lose the comma on this 
line if you do re-roll.

>   Note that a rebase merge works by replaying each commit from the working
> -branch on top of the <upstream> branch.  Because of this, when a merge
> +branch on top of the `<upstream>` branch.  Because of this, when a merge
>   conflict happens, the side reported as 'ours' is the so-far rebased
> -series, starting with <upstream>, and 'theirs' is the working branch.  In
> -other words, the sides are swapped.
> +series, starting with `<upstream>`, and 'theirs' is the working branch.
> +In other words, the sides are swapped.

Here when talking about "ours" and "theirs" as the parents of a merge we 
use single quotes ...

> -Because 'git rebase' replays each commit from the working branch
> -on top of the <upstream> branch using the given strategy, using
> -the 'ours' strategy simply empties all patches from the <branch>,
> +Because `git rebase` replays each commit from the working branch
> +on top of the `<upstream>` branch using the given strategy, using
> +the `ours` strategy simply empties all patches from the `<branch>`,

Here "ours" is an option argument so I think the backquotes make sense

> @@ -371,8 +371,8 @@ See also INCOMPATIBLE OPTIONS below.
>   --strategy-option=<strategy-option>::
>   	Pass the <strategy-option> through to the merge strategy.
>   	This implies `--merge` and, if no strategy has been
> -	specified, `-s ort`.  Note the reversal of 'ours' and
> -	'theirs' as noted above for the `-m` option.
> +	specified, `-s ort`.  Note the reversal of `ours` and
> +	`theirs` as noted above for the `-m` option.

Here "ours" and "theirs" are options so using backquotes is probably the 
right thing to do, but the text is referring to the section where they 
are not backquoted which confused me initially.

>   --verify::
>   	Allows the pre-rebase hook to run, which is the default.  This option can

Lower down some hook names are in double quotes which is probably a good 
idea but not strictly related to your patch.

> -apply backend: When applying a patch, ignore changes in whitespace in
> +'apply backend:' When applying a patch, ignore changes in whitespace in

I'm not sure if we want to say
     'apply backend:'
or
     'apply' backend:
>   
>   -x <cmd>::
>   --exec <cmd>::
> -	Append "exec <cmd>" after each line creating a commit in the
> -	final history. <cmd> will be interpreted as one or more shell
> +	Append `exec <cmd>` after each line creating a commit in the

Lower down when talking about other todo list commands we refer to them 
as "pick" (with double quotes) so I wonder if we should use "exec 
`<cmd>`" here as it is only <cmd> that comes from the command line argument

> -git rebase has two primary backends: apply and merge.  (The apply
> -backend used to be known as the 'am' backend, but the name led to
> -confusion as it looks like a verb instead of a noun.  Also, the merge
> +`git rebase` has two primary backends: `apply` and `merge`.  (The `apply`
> +backend used to be known as the `am` backend, but the name led to
> +confusion as it looks like a verb instead of a noun.  Also, the `merge`

I think using single quotes for the backend names might make more sense 
as they are just names.

> -When the git-rebase command is run, it will first execute a "pre-rebase"
> +When the `git rebase` command is run, it will first execute a "pre-rebase"

This is the section I was referring to earlier when talking about 
quoting hook names.

Thanks for working on this, it is great to have more consistent markup 
in the documentation

Best Wishes

Phillip