Nazri Ramliy <ayiehere@xxxxxxxxx> writes:
> Subject: git: run in a directory given with -C option
>
> This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
The doubled-"to to" which I locally fixed when I queued the last one
(together with other rewording to make it more agreeable and easier
to read) somehow came back ;-) Will fix locally again.
> +-C <path>::
> + Run as if git was started in '<path>' instead of the current working
> + directory. When multiple '-C' options are given, each subsequent
I think this should be `-C` to typeset it as "typed literally".
> + non-absolute `-C <path>` is interpreted relative to the preceding `-C
> + <path>`.
> ++
> +This option affects options that expect path name like '--git-dir' and
> +'--work-tree' in that their interpretations of the path names would be
Likewise for `--git-dir` and `--work-tree`.
> +made relative to the working directory caused by the '-C' option. For
and here.
> diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
> new file mode 100755
> index 0000000..c0006da
> --- /dev/null
> +++ b/t/t0056-git-C.sh
> @@ -0,0 +1,82 @@
> +#!/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") &&
Curious why this does not use -C here.
> + 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 &&
Because "a.txt" exists in both dir1 and dir1/dir2, this has less
chance of catching a bug (if somebody breaks the feature to run it
in dir1 not dir1/dir2, "add" will happily say "Oh, I found something
to add", instead of saying "Huh? there is no such path".
If you used b.txt instead, you would catch such a breakage.
Remember, tests are not about demonstrating how cool the new feature
is and/or how well it works in an expected setting. Imagine ways
other people can break your spiffy new feature in later patches, and
design tests that are more likely to catch them.
The same comment applies throughout the remainder of this script.
> + echo "initial in dir1/dir2" >expected &&
> + git -C dir1/dir2 commit -m "initial in dir1/dir2" &&
to reduce possibilities of breaking this test in the future due to
typos (e.g. somebody may want to say "initial commit in dir1/dir2"),
doing this may be a better idea:
msg="initial in dir1/dir2" &&
echo "$msg" >expected &&
git -C dir1/dir2 commit -m "$msg" &&
The same comment applies to the previous one.
--
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