# [PATCH] Teach git to change to a given directory using -C option 5 messages from 2013-04-19 to 2013-04-21. Participants: Nazri Ramliy, Jeff King, Jonathan Nieder. Thread: https://gitlist.dev/t/33544 ## Nazri Ramliy, 2013-04-19 12:21 Subject: [PATCH] Teach git to change to a given directory using -C option Message-ID: <1366374108-23725-1-git-send-email-ayiehere@gmail.com> URL: https://gitlist.dev/e/1366374108-23725-1-git-send-email-ayiehere%40gmail.com ``` This is similar in spirit to to "make -C dir ..." and "tar -C dir ...". Signed-off-by: Nazri Ramliy --- Often I find myself needing to find out quickly the status of a repository that is not in my currenct working directory, like this: $ (cd ~/foo; git log -1) With this patch now i can simply do: $ git -C ~/.zsh log -1 That's just one example. I think those who are familiar with the -C arguments to "make" and "tar" commands would get the "handiness" of having this option in git. Documentation/git.txt | 3 +++ git.c | 11 ++++++++++- t/t0050-filesystem.sh | 9 +++++++++ 3 files changed, 22 insertions(+), 1 deletion(-) 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 :: + Change to given directory before doing anything else. + -c =:: Pass a configuration parameter to the command. The value given will override values from configuration files. diff --git a/git.c b/git.c index 1ada169..6426a2e 100644 --- a/git.c +++ b/git.c @@ -53,7 +53,16 @@ static int handle_options(const char ***argv, int *argc, int *envchanged) /* * Check remaining flags. */ - if (!prefixcmp(cmd, "--exec-path")) { + if (!prefixcmp(cmd, "-C")) { + if (*argc < 2) { + fprintf(stderr, "No directory given for -C.\n" ); + usage(git_usage_string); + } + if (chdir((*argv)[1])) + die_errno("Cannot change to '%s'", (*argv)[1]); + (*argv)++; + (*argc)--; + } else if (!prefixcmp(cmd, "--exec-path")) { cmd += 11; if (*cmd == '=') git_set_argv_exec_path(cmd + 1); diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 05d78d2..ef1cb75 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -88,6 +88,15 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' ' test "z$(git cat-file blob :$camel)" = z1 ' +test_expect_success 'git -C changes directory to ' ' + test_create_repo dir1 && + echo 1 >dir1/a.txt && + git -C dir1 add a.txt && + git -C dir1 commit -m "initial in dir1" && + t1=$(git -C dir1 log --format=%s) && + test "$t1" = "initial in dir1" +' + test_expect_success "setup unicode normalization tests" ' test_create_repo unicode && cd unicode && -- 1.8.2.1.339.g52a3e01 ``` ## Jeff King, 2013-04-19 16:12 Subject: Re: [PATCH] Teach git to change to a given directory using -C option Message-ID: <20130419161250.GC14263@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130419161250.GC14263%40sigill.intra.peff.net In-Reply-To: <1366374108-23725-1-git-send-email-ayiehere@gmail.com> ``` On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote: > This is similar in spirit to to "make -C dir ..." and "tar -C dir ...". > > Signed-off-by: Nazri Ramliy > --- > Often I find myself needing to find out quickly the status of a repository that > is not in my currenct working directory, like this: > > $ (cd ~/foo; git log -1) > > With this patch now i can simply do: > > $ git -C ~/.zsh log -1 > > That's just one example. I think those who are familiar with the -C arguments > to "make" and "tar" commands would get the "handiness" of having this option in > git. This motivation should probably go into the commit message. I think it's worth pausing for a moment and considering if we can do this already with existing features. You can _almost_ do this with "git --git-dir". But it expects the actual git directory, not a starting point for finding the git directory. And it remains in your same working dir. So with a bare repository, these two are equivalent: $ git --git-dir=/path/to/foo.git ... $ git -C /path/to/foo.git ... But with a non-bare repo, this does not work: $ git --git-dir=/path/to/non-bare ... You must instead say: $ git --git-dir=/path/to/non-bare/.git ... and even then, I think it will treat your current directory as the working tree, not /path/to/non-bare. So I think "-C" is a worthwhile addition compared to just "--git-dir". It is redundant with "(cd foo && git ...)" in the shell, as you note, but sometimes it is more convenient to use "-C" (especially if you are exec-ing git from another program and want to avoid the shell entirely for quoting reasons). > 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 :: > + 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. > + if (!prefixcmp(cmd, "-C")) { Should this be strcmp? You do not seem to handle "-Cfoo" below. > + if (*argc < 2) { > + fprintf(stderr, "No directory given for -C.\n" ); > + usage(git_usage_string); > + } I know you are copying this from the other options in the same function, but I wonder if they should all be calling "error()" (and dropping the terminating ".") to better match our usual error messages. > + if (chdir((*argv)[1])) > + die_errno("Cannot change to '%s'", (*argv)[1]); > + (*argv)++; > + (*argc)--; You would want to set "*envchanged = 1" here. The intent of that flag is that git would need to throw away things it has looked up already (like the git dir) in order to correctly utilize the options (and since we haven't implemented that "throw away" step, it just complains and dies). I didn't try it, but I suspect your patch would be broken with: $ git config alias.logfoo '-C /path/to/foo log' $ cd /some/other/repo $ git logfoo It would still use /some/other/repo as a $GIT_DIR, having looked it up before processing the "-C". -Peff ``` ## Jonathan Nieder, 2013-04-20 22:18 Subject: Re: [PATCH] Teach git to change to a given directory using -C option Message-ID: <20130420221752.GA9980@elie.Belkin> URL: https://gitlist.dev/e/20130420221752.GA9980%40elie.Belkin In-Reply-To: <20130419161250.GC14263@sigill.intra.peff.net> ``` Jeff King wrote: > On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote: >> Often I find myself needing to find out quickly the status of a repository that >> is not in my currenct working directory, like this: >> >> $ (cd ~/foo; git log -1) >> >> With this patch now i can simply do: >> >> $ git -C ~/.zsh log -1 >> >> That's just one example. [...] > You can _almost_ do this with "git --git-dir". But it expects the actual > git directory, not a starting point for finding the git directory. [...] > It is redundant with "(cd foo && git ...)" in the shell, as you note, > but sometimes it is more convenient to use "-C" (especially if you are > exec-ing git from another program and want to avoid the shell entirely > for quoting reasons). When I want to run "git log" for a repository outside the cwd, I do use --git-dir (or more precisely, $ GIT_DIR=$HOME/src/git/.git git log ), which works. The "sometimes you just want to pass a command to 'exec'" use case does not convince me. I equally well might want to run "git" after another command, or run "git" if and only if a repository exists there, or do any number of other things. If someone asked me how to do that by passing a command to 'exec', I'd point them to sh -c 'cd foo && git ...' as a way to answer all such questions at the same time. So we're left with "--git-dir does not automatically append .git when appropriate" as the problem being solved, which is a real problem. Maybe that is worth fixing more directly? It might also be convenient to be able to do something like git --git-dir=~/src/git log -- Documentation/ which this -C option makes easy. *checks* Actually it works without, but for subtle reasons. A more sensible way to spell that is git --git-dir= -- :/Documentation/ which works fine. 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. Thanks for an interesting patch, and hope that helps, Jonathan ``` ## Jeff King, 2013-04-21 03:58 Subject: Re: [PATCH] Teach git to change to a given directory using -C option Message-ID: <20130421035857.GC18890@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130421035857.GC18890%40sigill.intra.peff.net In-Reply-To: <20130420221752.GA9980@elie.Belkin> ``` On Sat, Apr 20, 2013 at 03:18:38PM -0700, Jonathan Nieder wrote: > The "sometimes you just want to pass a command to 'exec'" use case > does not convince me. I equally well might want to run "git" after > another command, or run "git" if and only if a repository exists > there, or do any number of other things. Sure. I don't claim that it solves every problem, just that I have wanted it in that situation before. > So we're left with "--git-dir does not automatically append .git when > appropriate" as the problem being solved, which is a real problem. > Maybe that is worth fixing more directly? I'm a little hesitant, because --git-dir is _not_ "pretend like I am in directory X". Even though people may use it that way for bare repositories, it explicitly does not change your working tree. I'm not sure what rule you are proposing. If it is: 1. When we get "--git-dir=a/b", look in "a/b/.git" (assuming a/b is not a repo itself). 2. When we get "--git-dir=a/b", do the usual repo search from a/b, finding the first of "a/b", "a/b/.git", "a/.git". The second one is what makes me nervous, as it seems too much like "pretend that we are in a/b". But the first one seems kind of hack-ish. I suppose it is similar to the enter_repo rule used to find remotes, though, so at least there is some precedence. > It might also be convenient to be able to do something like > > git --git-dir=~/src/git log -- Documentation/ > > which this -C option makes easy. *checks* Actually it works without, > but for subtle reasons. I'm not sure what subtle reason that is. It does not seem to work for me: $ (cd git && git log -- Documentation | wc -l) 99152 $ git --git-dir=git log -- Documentation | wc -l fatal: Not a git repository: 'git' 0 A more interesting subtlety is this: $ git --git-dir=git/.git log -- Documentation | wc -l 99152 $ git --git-dir=git/.git log Documentation | wc -l fatal: ambiguous argument 'Documentation': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' 0 > 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. Yeah, I pretty much feel the same way. "git -C" is a concept that has occurred to me several times over the years, and I always dismissed it as "bah, you can do the same thing easily with one line of shell". It makes sense to me because of the precedence in other programs and I would probably use it, but I could also live without it. I do not mind it if it is not a maintenance burden. -Peff ``` ## Nazri Ramliy, 2013-04-21 13:48 Subject: [PATCH] Teach git to change to a given directory using -C option Message-ID: <1366552126-6090-1-git-send-email-ayiehere@gmail.com> URL: https://gitlist.dev/e/1366552126-6090-1-git-send-email-ayiehere%40gmail.com In-Reply-To: <20130419161250.GC14263@sigill.intra.peff.net> ``` This is similar in spirit to to "make -C dir ..." and "tar -C dir ...". Currently finding out the status of a git repository that is located away from the current working directory without going to that directory can be done in the following ways: 1. (cd ~/foo && git status) 2. git --git-dir=~/foo/.git --work-dir=~/foo status 3. GIT_DIR=~/foo/.git GIT_WORK_TREE=~/foo git status While doable the methods shown above are arguably more suitable for scripting than quick command line invocations. With this new option, the above can be done a bit more tersely: $ git -C ~/foo status A new test script is added to verify the behavior of this option with other path-related options like --git-dir and --work-tree. Signed-off-by: Nazri Ramliy --- Jeff: Thanks for pointing out the mistakes. But I did not address your concern: > I know you are copying this from the other options in the same function, > but I wonder if they should all be calling "error()" (and dropping the > terminating ".") to better match our usual error messages. because I'd rather have that fix be done in a separate topic. The other points raised are all valid and fixed in this new patch. Documentation/git.txt | 13 +++++++++ git.c | 15 ++++++++-- t/t0056-git-C.sh | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 102 insertions(+), 2 deletions(-) create mode 100755 t/t0056-git-C.sh diff --git a/Documentation/git.txt b/Documentation/git.txt index 6a875f2..6064b3d 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -379,6 +379,19 @@ displayed. See linkgit:git-help[1] for more information, because `git --help ...` is converted internally into `git help ...`. +-C :: + Run as if git were started in instead of the current + working directory. If multiple -C options are given, subsequent + directory arguments are interpreted relative to the previous one: -C + /usr -C src is equivalent to -C /usr/src. 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 + effective 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 + -c =:: Pass a configuration parameter to the command. The value given will override values from configuration files. diff --git a/git.c b/git.c index 1ada169..a8731e9 100644 --- a/git.c +++ b/git.c @@ -6,7 +6,7 @@ #include "run-command.h" const char git_usage_string[] = - "git [--version] [--help] [-c name=value]\n" + "git [--version] [--help] [-C directory] [-c name=value]\n" " [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n" " [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n" " [--git-dir=] [--work-tree=] [--namespace=]\n" @@ -53,7 +53,18 @@ static int handle_options(const char ***argv, int *argc, int *envchanged) /* * Check remaining flags. */ - if (!prefixcmp(cmd, "--exec-path")) { + if (!strcmp(cmd, "-C")) { + if (*argc < 2) { + fprintf(stderr, "No directory given for -C.\n" ); + usage(git_usage_string); + } + if (chdir((*argv)[1])) + die_errno("Cannot change to '%s'", (*argv)[1]); + if (envchanged) + *envchanged = 1; + (*argv)++; + (*argc)--; + } else if (!prefixcmp(cmd, "--exec-path")) { cmd += 11; if (*cmd == '=') git_set_argv_exec_path(cmd + 1); diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh new file mode 100755 index 0000000..370eae6 --- /dev/null +++ b/t/t0056-git-C.sh @@ -0,0 +1,76 @@ +#!/bin/sh + +test_description='"-C " option and it effects on other path-related options' + +. ./test-lib.sh + +test_expect_success '"git -C " runs git from the directory ' ' + test_create_repo dir1 && + echo 1 >dir1/a.txt && + (cd dir1 && git add a.txt && git commit -m "initial in dir1") && + expected="initial in dir1" && + actual=$(git -C dir1 log --format=%s) && + test "$expected" = "$actual" +' + +test_expect_success 'Multiple -C options: "-C dir1 -C dir2" is equivalent to "-C dir1/dir2"' ' + test_create_repo dir1/dir2 && + echo 1 >dir1/dir2/a.txt && + git -C dir1/dir2 add a.txt && + expected="initial in dir1/dir2" && + git -C dir1/dir2 commit -m "$expected" && + actual=$(git -C dir1 -C dir2 log --format=%s) && + test "$expected" = "$actual" +' + +test_expect_success 'Effect on --git-dir option: "-C c --git-dir=a.git" is equivalent to "--git-dir c/a.git"' ' + mkdir c && + mkdir c/a && + mkdir c/a.git && + (cd c/a.git && git init --bare) && + echo 1 >c/a/a.txt && + git --git-dir c/a.git --work-tree=c/a add a.txt && + git --git-dir c/a.git --work-tree=c/a commit -m "initial" && + expected="$(git --git-dir=c/a.git log -1 --format=%s)" && + actual=$(git -C c --git-dir=a.git log -1 --format=%s) && + test "$expected" = "$actual" +' + +test_expect_success 'Order should not matter: "--git-dir=a.git -C c" is equivalent to "-C c --git-dir=a.git"' ' + expected="$(git -C c --git-dir=a.git log -1 --format=%s)" && + actual=$(git --git-dir=a.git -C c log -1 --format=%s) && + test "$expected" = "$actual" +' + +test_expect_success 'Effect on --work-tree option: "-C c/a.git --work-tree=../a" is equivalent to "--work-tree=c/a --git-dir=c/a.git"' ' + rm c/a/a.txt && + expected="$(git --git-dir=c/a.git --work-tree=c/a status)" && + actual="$(git -C c/a.git --work-tree=../a status)" && + test "$expected" = "$actual" +' + +test_expect_success 'Order should not matter: "--work-tree=../a -C c/a.git" is equivalent to "-C c/a.git --work-tree=../a"' ' + expected="$(git -C c/a.git --work-tree=../a status)" && + actual="$(git --work-tree=../a -C c/a.git status)" && + test "$expected" = "$actual" +' + +test_expect_success 'Effect on --git-dir and --work-tree options - "-C c --git-dir=a.git --work-tree=a" is equivalent to "--git-dir=c/a.git --work-tree=c/a"' ' + expected="$(git --git-dir=c/a.git --work-tree=c/a status)" && + actual="$(git -C c --git-dir=a.git --work-tree=a status)" && + test "$expected" = "$actual" +' + +test_expect_success 'Order should not matter: "-C c --git-dir=a.git --work-tree=a" is equivalent to "--git-dir=a.git -C c --work-tree=a"' ' + expected="$(git -C c --git-dir=a.git --work-tree=a status)" && + actual="$(git --git-dir=a.git -C c --work-tree=a status)" && + test "$expected" = "$actual" +' + +test_expect_success 'Order should not matter: "-C c --git-dir=a.git --work-tree=a" is equivalent to "--git-dir=a.git --work-tree=a -C c"' ' + expected="$(git -C c --git-dir=a.git --work-tree=a status)" && + actual="$(git --git-dir=a.git --work-tree=a -C c status)" && + test "$expected" = "$actual" +' + +test_done -- 1.8.2.1.339.g52a3e01 ```