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

quoted

+	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