On January 10, 2018 1:16 PM, Johannes Sixt wrote: > Am 10.01.2018 um 01:12 schrieb Randall S. Becker: > > On January 9, 2018 6:01 PM, Johannes Sixt wrote: > > I'm encountering strange warnings, while looking into the details of what > test t0001 fails in spots. These include: > > #24 warning: templates not found x00000000000000...[lots of 0 > > deleted...]00000000000000000000 which exceeds 2K, but that's just > content, right, and not causing an apparent breakage. > > This warning occurs also on Linux and Windows. I think it is by design and > not something to be fixed. > > > > > # 34. Admittedly it was shorter than 2K, but there is something weird in this > path that I can't find, causing a failure out of fts_read from gnulib. > > Initialized empty Git repository in /home/ituglib/randall/git/t/trash > > directory.t0001- > init/123456789abcdef/123456789abcdef/123456789abcdef/1 > > > 23456789abcdef/123456789abcdef/123456789abcdef/123456789abcdef/123 > 4567 > > 89abcdef/newdir/.git/ > > rm: fts_read failed: No such file or directory > > > > This error is coming from some of shell utilities (in this case rm) > > used in the test rather than git code itself. > > So, the problem is not in the git executable. This does not warrant a change > in the build process, yet. > > > While well within the > > supported path length of the operating system/platform (1K), there is > > an acknowledged issue that is causing breakage when paths get large > > enough (even only this large, unfortunately). We're at 221 breaks out > > of 12982-ish, which is good, but have to otherwise visually check each > > breakage until the fts_read problem is resolved - I know what the > > issue is, but I don't have the auth to resolve it, so waiting on HPE > > platform development for that. Of course, manually patching that many > > breaks is equally unwieldy, so I'm willing to tolerate not having this > > patch applied at this time. > > Let me propose a different workaround. In my build on Windows, I inject a > few blind spots in the test suite using GIT_SKIP_TESTS for cases where I do > not have time to find a fix. It looks like this: > > diff --git a/t/Makefile b/t/Makefile > index 96317a35f4..fd8b18c3c0 100644 > --- a/t/Makefile > +++ b/t/Makefile > @@ -103,3 +103,19 @@ perf: > $(MAKE) -C perf/ all > > .PHONY: pre-clean $(T) aggregate-results clean valgrind perf > + > +# see > +https://public-inbox.org/git/alpine.DEB.2.21.1.1710260008270.37495@virt > +ualbox/ # the suggested solution is for MSYS2; don't have time to fix > +this for MSYS GIT_SKIP_TESTS += t0021.1[5-9] t0021.2[0-6] # special > +file names GIT_SKIP_TESTS += t1300.14[02] # GIT_SSH_COMMAND with args > +forwarded incompletely via git clone to test_fake_ssh GIT_SKIP_TESTS += > +t5601.5[01] # unknown failure in shallow submodule test GIT_SKIP_TESTS > ++= t7406.46 # mktemp missing? > +GIT_SKIP_TESTS += t7610.22 > +export GIT_SKIP_TESTS > + > +NO_SVN_TESTS=SkipThem > +export NO_SVN_TESTS > -- > > Build the list of test cases that do not pass, until the test suite runs through. > Then start fixing the cases. > > It is not foolproof, but very effective in keeping the focus on new cases. You > have to run tests with 'make' so that the variable is picked up. Also, when > somebody adds new tests in front of the mentioned cases, the numbers > must be adjusted. I can live with this. Thanks for your advice. Let's hold off on applying my approach. Cheers, Randall
