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