Lea Wiemann <lewiemann@xxxxxxxxx> writes: > Junio C Hamano wrote: >> With this on top of your parse_rev patch (I used v2 but I do not think v3 >> changes the situation in any way), you seem to have broken t9500. >> >> [...] I suspect that you are not using your own Git in the build tree in >> your test, but an already installed one. > > That was indeed the case, thanks for pointing it out! > > However, after applying my two patches and your patch on a pristine > current git.git clone, I still don't get an error... If you applied the "this on top of yours" fix, you shouldn't have seen any breakage. The breakage was not about what you did in Git.pm, but about adding "use Git" in gitweb.perl but without arranging it to find Git.pm (I do not have any git installed in usual places on my machine, and I strip the directory I keep my git installation out of my $PATH when running tests, to make sure "make test" can bootstrap itself without first installing). > How about putting this into test-lib.sh? There are more tests (like > my new Git.pm test suite) that will need it, so setting it up in a > central place would probably more convenient and prevent future > problems of this sort. Sure, I think that would be sensible. > If PERL5LIB already contains paths, can we just discard them, or > should we preserve them? It would be best to keep the existing one but make ours the first thing to be found, so that we will be sure that we test the one we just built. > Since perl/Makefile only copies Git.pm to blib/lib/Git.pm, we could > also set the path to ../../perl, which would prevent us from > accidentally running tests against an old version of Git.pm (because > we haven't run cd perl; make before). And perhaps add a comment to > perl/Makefile about this, in case someone wants to change the build > process in the future. Or is there some reason why this would be a bad > idea? I think it is a bad idea. In principle we should be testing what we just built and will install; even if currently the "building procedure" for blib/lib/Git.pm may happen to be bit-for-bit copy of the original, that is just by accident and not something we would want to rely on. -- 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
