Re: [PATCH 1/6] test-lib: introduce test_commit_bulk

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Fri, Jun 28, 2019 at 07:46:02PM -0400, Eric Sunshine wrote:
> On Fri, Jun 28, 2019 at 7:04 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > On Fri, Jun 28, 2019 at 05:32:35PM -0400, Eric Sunshine wrote:
> > > On Fri, Jun 28, 2019 at 5:39 AM Jeff King <peff@peff.net> wrote:
> > > > +       in_dir=${indir:+-C "$indir"}
> > >
> > > Doesn't this suffer the problem in which some older/broken
> > > shells[1][2][3][4] incorrectly [...]
> >
> > I think we don't need any of those "${indir:+-C "$indir"}" parameter
> > expansions and could simply use 'git -C "$indir" cmd...' everywhere.
> > $indir is set to empty right at the start of the function, and 'git -C
> > "" ...' works and doesn't change the working directory.
> 
> I recall the discussion around the meaning of `-C ""` when that
> command line option was introduced. The conclusion was that  the
> zero-length argument should mean "this directory" since that's how `cd
> ""` behaves. However, I don't think that behavior ever got documented,

Although it's not documented (but see the patch below), we do
explicitly test it since 6a536e2076 (git: treat "git -C '<path>'" as a
no-op when <path> is empty, 2015-03-06) and e.g. our completion script
relies on this behavior.

> and it's not necessarily obvious. An alternative would be to default
> 'indir' to ".", which should give the same result and be easily
> understood.

That's fine for me as well.


   --- >8 ---

Subject: [PATCH] Document that 'git -C ""' works and doesn't change directory

It's been behaving so since 6a536e2076 (git: treat "git -C '<path>'"
as a no-op when <path> is empty, 2015-03-06).

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 Documentation/git.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index f9b09db89b..a9deca0acb 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -57,7 +57,8 @@ help ...`.
 	Run as if git was started in '<path>' instead of the current working
 	directory.  When multiple `-C` options are given, each subsequent
 	non-absolute `-C <path>` is interpreted relative to the preceding `-C
-	<path>`.
+	<path>`.  If '<path>' is present but empty, e.g. `-C ""`, then the
+	current working directory is left unchanged.
 +
 This option affects options that expect path name like `--git-dir` and
 `--work-tree` in that their interpretations of the path names would be
-- 
2.22.0.589.g5bd7971b91