git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] test: make SYMLINKS prerequisite more robust
Date: Wed, 08 Feb 2023 17:56:59 -0800	[thread overview]
Message-ID: <xmqqbkm3ppn8.fsf@gitster.g> (raw)
In-Reply-To: <230209.86k00rzqsz.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Thu, 09 Feb 2023 00:09:46 +0100")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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 ;-)

  reply	other threads:[~2023-02-09  1:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08 19:40 [PATCH] test: make SYMLINKS prerequisite more robust Junio C Hamano
2023-02-08 23:09 ` Ævar Arnfjörð Bjarmason
2023-02-09  1:56   ` Junio C Hamano [this message]
2023-02-09  2:15     ` Ævar Arnfjörð Bjarmason
2023-02-09 22:54       ` Junio C Hamano
2023-02-10 17:31     ` Junio C Hamano
2023-02-10 19:39       ` Ævar Arnfjörð Bjarmason
2023-02-13  9:12       ` Johannes Schindelin
2023-02-13 18:07         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbkm3ppn8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).