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
