On Tue, Sep 3, 2013 at 6:46 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Nazri Ramliy <ayieh...@gmail.com> 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
>>  --------
>>  [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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to