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

[Jeff King <peff@peff.net>]

On Fri, Jun 28, 2019 at 10:53:41AM -0700, Junio C Hamano wrote:

> > +	in_dir=${indir:+-C "$indir"}
> 
> I thought that this assignment to $in_dir would be unnecessary if we
> parsed -C directly into it, i.e.

Heh, sorry for the confusion. That in_dir is leftover cruft. I was
trying to see if I could then expand it as:

  git $in_dir some-cmd ...

to make the git calls more readable. But that doesn't work if $indir has
whitespace, so I abandoned it (we're relying on whitespace splitting
between "-C" and the argument, but we don't want it split on the
argument).

I _also_ mispelled $indir as $in_dir in that attempt, which meant that
the leftover line did not break anything, and I didn't notice. But it
can just go away.

> 		-C)
> 			in_dir="-C $indir"
> 			shift
> 			;;
> 		...
> 
> but you probably could pass -C '' to defeat an $in_dir that was set
> earlier by using a separate variable?

I don't know if "-C ''" works with Git or not. I had contemplated
defaulting indir to ".", so that we did:

  git -C . command ...

which I think would work (at the minor cost of a useless chdir() inside
the C process).

In the end I just stole the technique that test_commit uses. It's a
little ugly, but there are only 3 calls.

> Reading further, though, I do not seem to see where this variable is
> referred to, and that is the answer to my puzzlement.  This must be
> a leftover that was written once before but no longer is used.  We
> can remove $in_dir while keeping the initialization and assignment
> to $indir as-is, I think.

Yes. :)

> All uses of $indir in the remainder of the function look $IFS-safe,
> which is good.

Yeah, I think it should be (though since most callers pass relative
paths for these kind of one-off -C uses, it's actually pretty rare for
it to matter).

-Peff