Re: [PATCH v2 3/4] Documentation: format full commands in typewriter font
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 10, 2010, 03:31 UTC
- Message-ID
- <20100110033133.GE1083@progeny.tock>
- In-Reply-To
- <9d10ee6a8526dc9f9c220cc6bb4b509c8cc73b0a.1263081032.git.trast@student.ethz.ch>
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.
Show 19 quoted lines
> 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?
Show 10 quoted lines
> 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)?
Show 13 quoted lines
> 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’...
Show 8 quoted lines
> --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.
Show 10 quoted lines
> 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@gmail.com>
The rest looks good, and really does seem clearer in some places.
Thanks, Jonathan