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.
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