Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> I wonder if something like this is in order? > > I don't have much to contribute on that front, but this is really > missing some "why", this worked before, why is it failing now? Do we > have any idea. Your guess is as good as mine. I do not do Windows. Thanks for independently noticing the uninitialized strbuf. What I have queued has it fixed already locally but there isn't much point to send another copy out to the list ;-). > All in all a simple helper, but isn't this redundant to "test_readlink"? Not at all. We need to avoid the Perl one for this purpose. What matters is whether "git" considers if symlink is working. Perhaps our readlink(3) emulation we have in compat/ may hardcode our "knowledge" that symlink is not available in Windows, which may not match what the POSIX XCU emulation in our Windows environment offers, which apparently ran "ln -s x y && test -h y" successfully, and who knows what test_readlink that is written in Perl thinks? We are testing "git" with the test suite, so even if with some magic that is still unknown to compat/mingw.h it knows how to read what "ln -s x y" left in "y", until compat/mingw.h::readlink() learns the same trick, asking Perl to decide SYMLINKS prerequisite would not help our test scripts at all. > echo x >expect && > test-tool readlink y >actual && > test_cmp expect actual > > If you're trying to avoid leaving litter or cleaning up that's not > needed anymore with these lazy prereqs for a while now (they get their > throw-away temporary directory). Indeed, I just did not want to add another cruft, but 'x' and 'y' are already such crufts, so I could have just done ln -s x y && test -h y && test-tool readlink y >x && test $(cat x) = x to use one of them ;-)
