Re: [PATCH 4/6] config: return configset value for current_config_ functions
- From
Jeff King <peff@peff.net>
- Date
- May 19, 2016, 00:08 UTC
- Message-ID
- <20160519000821.GA22543@sigill.intra.peff.net>
- In-Reply-To
- <20160518224323.GD22443@sigill.intra.peff.net>
On Wed, May 18, 2016 at 06:43:23PM -0400, Jeff King wrote:
Show 9 quoted lines
> cache.h | 1 + > config.c | 51 +++++++++++++++++++++++++++++++++++++++++--------- > t/helper/test-config.c | 20 ++++++++++++++++++++ > t/t1308-config-set.sh | 23 +++++++++++++++++++++++ > [...] > +test_expect_success 'iteration shows correct origins' ' > + echo "[alias]test-config = !test-config" >.gitconfig && > [...] > + git -c foo.bar=from-cmdline test-config iterate >actual &&
While writing and testing this, I got bit by e6e7530 (test helpers: move test-* to t/helper/ subdirectory, 2016-04-13). I had an old test-config binary leftover in the root of my repository, and the new one was correctly built in t/helper/. Running "test-config" is fine, but inside the git alias, it sticks the repository root at the front of $PATH (because it's the exec-path). And so it ran the old version of test-config, which did not understand my new "iterate" option.
Now I'll admit what I'm doing here is pretty funny (running test-* from an alias). I'm doing it because I want to see how the program operates with the "-c" config, and it's nicer to spell it as a user would, instead of munging $GIT_CONFIG_PARAMETERS directly.
So I'm not sure if it's worth working around or not. The single tree state produced by this commit is fine, but it does behave badly if there's leftover cruft from a pre-e6e7530 build. A more robust version would look more like:
sq=\' ;# to ease quoting later
...
GIT_CONFIG_PARAMETERS=${sq}foo.bar=from-cmdline${sq} test-config ...Which is ugly, but it's probably worth it to avoid the flakiness.
The other option is to somehow make bin-wrappers more robust. E.g., it would be nice if we didn't actually point into the repository root directly, but rather somehow linked all of the git-* entries that _would_ be installed into the exec-path into a fake exec-path (or alternatively, actually build them directly into that fake exec-path).
That's a much bigger change, though. Given how unlikely the sequence of steps in my test is, maybe it's better to just work around it in this one case.
-Peff