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 >> 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  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>). : 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