Re: [PATCH 1/6] test-lib: introduce test_commit_bulk
- From
Jeff King <peff@peff.net>
- Date
- Jun 29, 2019, 00:14 UTC
- Message-ID
- <20190629001457.GD2625@sigill.intra.peff.net>
- In-Reply-To
- <xmqqlfxl8ul6.fsf@gitster-ct.c.googlers.com>
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.
Show 8 quoted lines
> -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.
Show 5 quoted lines
> 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