On Mon, Sep 2, 2013 at 9:39 AM, Nazri Ramliy <ayiehere@xxxxxxxxx> wrote:
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 83edf30..7a1369a 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -395,6 +395,20 @@ displayed. See linkgit:git-help[1] for more information,
> because `git --help ...` is converted internally into `git
> help ...`.
>
> +-C <path>::
> + Run as if git were started in <path> instead of the current working
> + directory. If multiple -C options are given, subsequent relative <path>
> + arguments are interpreted relative to the previous effective directory:
> + "-C /usr -C src" is equivalent to "-C /usr/src", while "-C src -C /usr"
> + is equivalent to "C /usr". This option affects options that expect path
No wish to bike-shed, however, I find "effective directory" somewhat
difficult to digest due to its jargony feel. It also seems ambiguous
(to me) since "previous effective directory" may mean "directory when
git was run" or "directory set by most recent -C". My earlier
suggestion
When multiple -C options are given, each subsequent non-absolute
-C <path> is interpreted relative to the preceding -C <path>.
avoided jargon and left no room for ambiguity.
However, perhaps the examples are clear enough to make excessive prose
explanation unnecessary, thus:
Run as if git was started in <path> instead of the current
working directory. Multiple -C options are allowed and acted upon
in the order given, thus "-C /usr -C src" is equivalent to "-C
/usr/src", and "-C src -C /usr" is equivalent to "C /usr". This
option affects ...
> diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
> new file mode 100755
> index 0000000..7dc1e48
> --- /dev/null
> +++ b/t/t0056-git-C.sh
> @@ -0,0 +1,83 @@
> +#!/bin/sh
> +
> +test_description='"-C <path>" option and its effects on other path-related options'
> +
> +. ./test-lib.sh
> +
> +test_expect_success '"git -C <path>" runs git from the directory <path>' '
> + test_create_repo dir1 &&
> + echo 1 >dir1/a.txt &&
> + (cd dir1 && git add a.txt && git commit -m "initial in dir1") &&
> + echo "initial in dir1" >expected &&
> + git -C dir1 log --format=%s >actual &&
> + test_cmp 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"
> + echo $expected >expected &&
> + git -C dir1/dir2 commit -m "$expected" &&
It's curious that this test uses a variable ($expected) to avoid
repeating literal "initial in dir1/dir2", however, the previous test
repeats its literal "initial in dir1". (IMHO, the repeated literal
actually makes the test a bit easier to read, and it's not likely to
be a maintenance burden.)
> + git -C dir1 -C dir2 log --format=%s >actual &&
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'Relative followed by fullpath: "-C ./here -C /there" is equivalent to "-C /there"' '
> + echo "initial in dir1/dir2" >expected &&
> + git -C dir1 -C "$PWD/dir1/dir2" log --format=%s >actual &&
It is suggested in t/README that, for Windows (MSYS bash)
compatibility, you should use $(pwd) rather than $PWD.
> + test_cmp expected actual
> +'
> +
> +test_done
> --
> 1.8.4.24.g5fcd118
--
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