On 26 Apr 2016, at 01:10, SZEDER Gábor <szeder@xxxxxxxxxx> wrote: > > Quoting Junio C Hamano <gitster@xxxxxxxxx>: > >> SZEDER Gábor <szeder@xxxxxxxxxx> writes: >> >>> You can have a look at these patches at >>> >>> https://github.com/szeder/git completion-test-multiple-bash-versions >>> >>> and perhaps you could even adapt it to LFS and/or p4 somehow. >>> >>>> Plus if we want to be consistent we would >>>> need to do the same for LFS 1.0, 1.2, and for pretty much every other >>>> dependency... >>> >>> I'm not sure we should be consistent in this case, at least not solely >>> for consistency's sake and not in git.git. Taking what I did for Bash >>> and doing it for different versions of LFS, p4, etc. could perhaps >>> keep the runtime under control, but t/Makefile would surely get out >>> of control rather quickly. Putting these into a travis-ci matrix is >>> so much simpler, but the runtime makes it infeasible, of course. >> >> I took a brief look of your branch, and I like its approach. If I >> understood your approach correctly, you: >> >> * Group selected tests in t/ as "these are bash related tests I >> care about" in t/Makefile; > > Yes. > >> * Add Travis test target to build Git with specific versions of >> bash, and run the above target instead of the full test to >> exercise the version of bash you are testing. > > Not quite. > > * Add t/Makefile targets to run a Bash-related test script with a > specific Bash version, one target for each script-version pair, > and a target to run all Bash-related tests with all listed > Bash-versions. > > * Extend the travis-ci config so that, after building Git as usual > and running the full test suite as usual, it additionaly runs all > Bash-related tests will all listed Bash versions on Linux builds. > >> And I agree that the same can be done for LFS versions and P4 >> versions. Only a handful tests in t/ are about these niches. > > Luckily for me, running a test script with a specific Bash version is > as trivial as '/path/to/bash-vX.Y t9902-completion.sh'. No > modifications to the test scripts or to lib-bash.sh were necessary. > > OTOH, Git LFS and p4 tests, AFAICS, rely on git-lfs and p4 binaries > being available in $PATH, and the p4 tests need two binaries. So > there is more work that has to be done, as we would need a way to > override those binaries found in $PATH, either through an environment > variable or a command line option. Bonus points for a solution that > would work equally well with LFS, p4 and Bash: then perhaps we could > have a single unified block of Makefile metaprogramming, which could > generate all those test targets from a list of dependency-specific > tests and a list of paths to different versions of that dependency. > Then it might even be suitable for inclusion in git.git. Thanks for sharing this! It's awesome! I will try to find a generic solution based on your work that handles bash versions, LFS versions, and P4 versions! Stay tuned :-) Cheers, Lars > > >>> I think the best we can do is to keep this out of git.git and let >>> (hope?) developers interested in a particular subsystem do this >>> "multiple version compatibility" tests as they see fit. > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html