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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 8, 2013 at 9:49 PM, Nazri Ramliy <ayiehere@xxxxxxxxx> wrote:
> On Sun, Sep 8, 2013 at 6:32 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]