On Sun, Sep 8, 2013 at 6:32 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote:
> For consistency with existing formatting in git.txt, you may want to
> squash in the following fixes (sans gmail whitespace damage):
> --- >8 ---
[ diff snipped ]
> --- >8 ---

Thanks. I'll submit a reroll later.

>> +This option affects options that expect path name like --git-dir and
>> +--work-tree in that their interpretations of the path names would be
>> +made relative to the working directory caused by the -C option. For
>> +example the following invocations are equivalent:
>> +
>> +    git --git-dir=a.git --work-tree=b -C c status
>> +    git --git-dir=c/a.git --work-tree=c/b status
> Is the interaction of -C with --work-tree and --git-dir desirable or
> useful? (I'm genuinely curious.) Do you have use-cases in mind? Would
> mentioning them in the commit message help to justify the interaction?

The example is meant to clarify the effect of the -C option, rather than a
proposed usage with the --work-tree and --git-dir options. The example came out
due to the following discussions from an earlier version of this patch [1]:

On Sat, Apr 20, 2013 at 12:12 AM, Jeff King <p...@peff.net> wrote:
> On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote:
>> diff --git a/Documentation/git.txt b/Documentation/git.txt
>> index 6a875f2..20bba86 100644
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -379,6 +379,9 @@ displayed. See linkgit:git-help[1] for more information,
>>  because `git --help ...` is converted internally into `git
>>  help ...`.
>> +-C <directory>::
>> +     Change to given directory before doing anything else.
>> +
> It might make sense to clarify this as "...anything else, including
> determining the location of the git repository directory". If you think
> hard about it, doing anything else would not really make much sense, but
> spelling it out makes it clear what the option can be used for.

and [2]:

On Sun, Apr 21, 2013 at 6:18 AM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> All that said, I don't mind -C terribly as long as it can maintain
> itself, which means including thorough documentation that covers the
> purpose and how pathname parameters and envvars interact with the new
> option and including tests under t/ to ensure it continues to work
> correctly in the future.


[1] http://article.gmane.org/gmane.comp.version-control.git/221766
[2] http://article.gmane.org/gmane.comp.version-control.git/221878
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