On Tue, Sep 3, 2013 at 6:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Nazri Ramliy <ayiehere@xxxxxxxxx> writes:
>
>> -- >8 --
>> diff --git a/Documentation/git.txt b/Documentation/git.txt
>> index 83edf30..6105cb0 100644
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -9,7 +9,7 @@ git - the stupid content tracker
>> SYNOPSIS
>> --------
>> [verse]
>> -'git' [--version] [--help] [-c <name>=<value>]
>> +'git' [--version] [--help] [-C <path>] [-c <name>=<value>]
>
> I do not care too deeply either way, but I am curious if there was a
> reason why you changed the earlier <directory> to <path>? Somehow,
> when we _know_ a path has to be a directory, I find it easier on the
> readers to spell that out, instead of saying "this is a path",
> implying that it could be a directory, a regular file, or even
> non-existent.
That change was in response to my review [1] in which I mentioned:
Other options which accept a directory, such as --git-dir and
--work-tree, are documented as accepting <path>, but -C is
inconsistently documented as accepting <directory>.
>> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
>> [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
>> [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
Thus <directory> was inconsistent with existing text in git.txt, such
as what is visible here for --git-dir and --work-tree, as well as
later in git.txt where --git-dir and --work-tree are described in more
detail (also using <path>).
[1]: http://thread.gmane.org/gmane.comp.version-control.git/233441/focus=233564
--
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