Hi Stolee
On 27/06/2022 22:21, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee <derrickstolee@xxxxxxxxxx>
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@xxxxxxxxxx>
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
