From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun, 10 Jan 2010 03:31:33 GMT
Subject: Re: [PATCH v2 3/4] Documentation: format full commands in typewriter font
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.

> 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@gmail.com>

The rest looks good, and really does seem clearer in some places.

Thanks,
Jonathan