git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Update git-p4 to be compatible with git-lfs 1.2

From
SZEDER Gábor <szeder@ira.uka.de>
Date
Apr 25, 2016, 23:10 UTC
Message-ID
<20160426011056.Horde.yl47nWMpVGsuGDgrKiKb_nR@webmail.informatik.kit.edu>
In-Reply-To
<xmqq8u01mwji.fsf@gitster.mtv.corp.google.com>
Quoting Junio C Hamano <gitster@pobox.com>:
Show 24 quoted lines
> SZEDER Gábor <szeder@ira.uka.de> 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.
Previous: Junio C HamanoNext: Lars Schneider
Message 9 of 10 in “Update git-p4 to be compatible with git-lfs 1.2”
  1. Update git-p4 to be compatible with git-lfs 1.2Ben Woosley, Apr 20, 2016
  2. Luke DiamandApr 20, 2016
  3. Ben WoosleyApr 20, 2016
  4. Lars SchneiderApr 20, 2016
  5. Ben WoosleyApr 20, 2016
  6. Lars SchneiderApr 22, 2016
  7. SZEDER GáborApr 25, 2016
  8. Junio C HamanoApr 25, 2016
  9. SZEDER GáborApr 25, 2016
  10. Lars SchneiderApr 28, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.