On 6/28/2022 5:59 AM, Phillip Wood wrote: > Hi Stolee > > On 27/06/2022 22:21, Derrick Stolee via GitGitGadget wrote: > 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. Thanks for taking such a close look! >> -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. Noted. Thanks. >> 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 ... Good point... >> -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 I agree. >> @@ -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. I think your confusion makes sense. Here, we are talking about "sides" of a merge and not a strategy. I'll fix this in v2. >> -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 Junio has some ideas about making this a bulletted list more clearly, so I'll try that and see what happens. >> -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. I was thinking of them similar to the merge strategies, but you're right that these are not used as CLI input (just something implied by --merge or --apply). I'll remove the ticks from around these uses. >> -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. Excellent. Will fix. Thanks, -Stolee
