Re: [PATCH v3] Teach git to change to a given directory using -C option

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sep 9, 2013, 05:01 UTC
Message-ID: <CAPig+cTNeqNhGwD-EZ3uszh5vJ4JeJ6L0RXdTsveb1FgXE5t3Q@mail.gmail.com>
In-Reply-To: <CAEY4ZpNEae1UprRcpC8XUPP4XBQ89bDXP1A7yVcFdW405HZr0w@mail.gmail.com>

On Sun, Sep 8, 2013 at 9:49 PM, Nazri Ramliy <ayiehere@gmail.com> wrote:

Show 17 quoted lines

> On Sun, Sep 8, 2013 at 6:32 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> +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]:
> [1] http://article.gmane.org/gmane.comp.version-control.git/221766

Thanks for the reference. I did read that thread earlier. It doesn't really answer my question, but perhaps it's not terribly important since the interaction is documented. I was mainly asking if the choice of locking in one particular interpretation was deliberate even though other potentially valid (and perhaps more intuitive) interpretations exists. More below TL;DR if you care to read on.

TL;DR

I was interested in knowing whether the exact interaction between -C and --work-tree and --git-dir was intentional (and desirable) or an "accident of implementation". I can see it going either way.

As implemented by the patch, -C is acted upon immediately (via chdir()), whereas --work-tree and --git-dir have a delayed effect, so:

  git -C foo --work-tree=bar -C baz --git-dir=moo

means:

  work-tree = foo/baz/bar
  git-dir = foo/baz/moo

However, it would be equally valid for a user to expect the options to be evaluated sequentially such that the above command line would mean:

  work-tree = foo/bar
  git-dir = foo/baz/moo

Is the former interpretation better than the latter possibly more intuitive interpretation? This is a genuine question. I'm not suggesting that one interpretation is better than the other, and it's possible that it won't matter in practice [1], but it might be good to know that alternate interpretations have been taken into consideration before locking in a particular behavior.

This is why I was asking if you had particular use-cases in mind where the former made more sense than the latter (or some other [2]) interpretation. Since there are multiple potential interpretations, it might make sense to explain in the commit message why the one was chosen over the other(s), and such use-cases could help solidify that explanation.

[1]: Mixing of -C, --work-tree, and --git-dir may be sufficiently unlikely that the reason the patch's behavior was chosen becomes immaterial. Since the behavior is documented, a person can choose to avoid -C if it doesn't work in a way suitable to his situation.

[2]: For example, a user might reasonably expect -C to be relative to --work-tree or GIT_WORK_TREE rather than the other way around. So, "git --work-tree=foo -C bar" or "git -C bar --work-tree=foo" would chdir("foo/bar") before performing the git operation, and --git-dir would be unaffected. Yet another possibility is that -C would impact neither --work-tree nor --git-dir.