From: Eric Sunshine <sunshine@sunshineco.com>
To: Nazri Ramliy <ayiehere@gmail.com>
Cc: Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH v2] Teach git to change to a given directory using -C option
Date: Tue, 3 Sep 2013 03:42:45 -0400 [thread overview]
Message-ID: <CAPig+cTQrjmiKYWoo57BTBNS0nuR+NMDf8uCk5EqAvcMzr0iVA@mail.gmail.com> (raw)
In-Reply-To: <20130902133911.GA23924@gmail.com>
On Mon, Sep 2, 2013 at 9:39 AM, Nazri Ramliy <ayiehere@gmail.com> 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
prev parent reply other threads:[~2013-09-03 7:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 13:39 [PATCH v2] Teach git to change to a given directory using -C option Nazri Ramliy
2013-09-03 7:42 ` Eric Sunshine [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPig+cTQrjmiKYWoo57BTBNS0nuR+NMDf8uCk5EqAvcMzr0iVA@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=ayiehere@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).