Thomas Rast wrote: > * If the intent is that the user type the command exactly as given, it > is `code`. > If the user is only loosely referred to a command and/or option, it > remains 'emphasised'. Okay. I think I was guilty of pushing this convention (in commits like 2fd02c92). If the distinction is too hazy to be useful, I think it would be fine to always use `code`, though that would be a bigger patch. > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 23a965e..6bfd9e1 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -741,15 +741,15 @@ diff.mnemonicprefix:: > standard "a/" and "b/" depending on what is being compared. When > this configuration is in effect, reverse diff output also swaps > the order of the prefixes: > -'git-diff';; > +`git diff`;; > compares the (i)ndex and the (w)ork tree; > -'git-diff HEAD';; > +`git diff HEAD`;; > compares a (c)ommit and the (w)ork tree; > -'git diff --cached';; > +`git diff --cached`;; > compares a (c)ommit and the (i)ndex; > -'git-diff HEAD:file1 file2';; > +`git-diff HEAD:file1 file2`;; Shouldn't this use ‘git diff’ (no hyphen)? Alternatively, if you are leaving this for the next commit, should the other 'git-diff' lines keep their dash until then, too? > diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt > index c39d957..f91c7ac 100644 > --- a/Documentation/git-bisect.txt > +++ b/Documentation/git-bisect.txt > @@ -26,7 +26,7 @@ on the subcommand: > git bisect log > git bisect run <cmd>... > > -This command uses 'git rev-list --bisect' to help drive the > +This command uses `git rev-list --bisect` to help drive the Does rev-list --bisect take more arguments (i.e., isn’t the command being only loosely referred to here)? > diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt > index 394a77a..544836a 100644 > --- a/Documentation/git-filter-branch.txt > +++ b/Documentation/git-filter-branch.txt > @@ -129,8 +129,8 @@ convenience functions, too. For example, calling 'skip_commit "$@"' > will leave out the current commit (but not its changes! If you want > that, use 'git-rebase' instead). > + > -You can also use the 'git_commit_non_empty_tree "$@"' instead of > -'git commit-tree "$@"' if you don't wish to keep commits with a single parent > +You can also use the `git_commit_non_empty_tree "$@"` instead of > +`git commit-tree "$@"` if you don't wish to keep commits with a single parent > and that makes no change to the tree. Not this commit’s topic, but perhaps ‘use the ...’ should be ‘use ...’ or ‘use the ... idiom’... > --tag-name-filter <command>:: > @@ -179,7 +179,7 @@ the nearest ancestor that was not excluded. > and only one parent, it will hence keep merges points. Also, this > option is not compatible with the use of '--commit-filter'. Though you > just need to use the function 'git_commit_non_empty_tree "$@"' instead > - of the 'git commit-tree "$@"' idiom in your commit filter to make that > + of the `git commit-tree "$@"` idiom in your commit filter to make that > happen. ... to match this. > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt > index 3277f4e..04c21d3 100644 > --- a/Documentation/git-merge.txt > +++ b/Documentation/git-merge.txt > @@ -193,7 +193,7 @@ After seeing a conflict, you can do two things: > > * Decide not to merge. The only clean-ups you need are to reset > the index file to the `HEAD` commit to reverse 2. and to clean > - up working tree changes made by 2. and 3.; 'git-reset --hard' can > + up working tree changes made by 2. and 3.; `git-reset --hard` can Probably `git reset --hard` (I won’t mention any more of these). Except for the bisect-change above, Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> The rest looks good, and really does seem clearer in some places. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html