Hi Peff, the other three patches look good to me. On Fri, 8 Dec 2017, Jeff King wrote: > You may want to run the test suite with a different shell > than you use to build Git. For instance, you may build with > SHELL_PATH=/bin/sh (because it's faster, or it's what you > expect to exist on systems where the build will be used) but > want to run the test suite with bash (e.g., since that > allows using "-x" reliably across the whole test suite). > There's currently no good way to do this. > > You might think that doing two separate make invocations, > like: > > make && > make -C t SHELL_PATH=/bin/bash > > would work. And it _almost_ does. The second make will see > our bash SHELL_PATH, and we'll use that to run the > individual test scripts (or tell prove to use it to do so). > So far so good. > > But this breaks down when "--tee" or "--verbose-log" is > used. Those options cause the test script to actually > re-exec itself using $SHELL_PATH. But wait, wouldn't our > second make invocation have set SHELL_PATH correctly in the > environment? > > Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we > built during the first "make". And that overrides the > environment, giving us the original SHELL_PATH again. ... and we could simply see whether the environment variable TEST_SHELL_PATH (which we would set in t/Makefile from the passed-in SHELL_PATH) is set, and override it again. I still think we can do without recording test-phase details in the build-phase (which may, or may not, know what the test-phase wants to do). In other words, I believe that we can make the invocation you mentioned above work, by touching only t/Makefile (to pass SHELL_PATH as TEST_SHELL_PATH) and t/test-lib.sh (to override the SHELL_PATH from GIT-BUILD-OPTIONS with TEST_SHELL_PATH, if set). Ciao, Dscho
