git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Andrei Rybak" <rybak.a.v@gmail.com>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>
Subject: Re: [PATCH] test-lib: fix "$remove_trash" regression and match_pattern_list() bugs
Date: Wed, 16 Jun 2021 11:49:20 +0200	[thread overview]
Message-ID: <87pmwmxd6f.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <YMm4F2uKZ4Dv3C4p@coredump.intra.peff.net>


On Wed, Jun 16 2021, Jeff King wrote:

> On Wed, Jun 16, 2021 at 10:24:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Those options will try to match an argument like --verbose-only=1*
>> against a test number like "10", but since we run the match in our own
>> trash directory an earlier test creating a file like "1one.txt" will
>> break that option.
>> 
>> We cannot simply quote the $GIT_SKIP_TESTS" being passed to
>> match_pattern_list(), since we are relying on the $IFS semantics.
>> 
>> Let's instead setup a .test-lib-trash subdirectory under the trash
>> directory, and an "empty-dir" directory under that. Then let's run the
>> match_pattern_list() in a sub-shell in that directory.
>
> Looks like my email just crossed with this one. Your "cd to an empty
> directory" is a fun version of my "maybe somebody can think of something
> clever" statement. :)

Yeah, I sent it before seeing yours.

> As a general solution, it does fail if the globs may contain things that
> look like absolute paths, but that is quite unlikely for our use case
> here.[...]

Not just unlikely, impossible. Yes it's possible in the general case,
but in the match_pattern_list we are always normalizing
e.g. ./t1234-some-test.sh t t1234, and the other match cases are test
numbers etc. It doesn't need to deal with the general case.

> [...] Still, I kind of like the "set -f" version because it doesn't need
> the extra directory which could cause problems with "ls-files -o", etc,
> as you mentioned. You could also create the empty directory on the fly,
> though if "set -f" works portably, that seems less complicated to me.

Yeah, in isolation I'd agree, but given the desire (with existing code
and other in-flight code) to have a scratch are for the test library
code itself simply creating such a directory seems like a good thing to
have in general, and once we have it we can use the subshell trick, or
just "set -f" I suppose and use the scratch dir for other stuff.

I am a bit wary of this being our first ever use of "set -f", but maybe
it's sufficiently portable.

> Whatever the expansion mechanism, I do think it's worth having callers
> quote "$GIT_SKIP_TESTS" and then performing the expansion within
> match_pattern_list. Then the nasty mechanics are all in that one place.

I think it's rather clean to not quote it, i.e. to have the loop get a
list of item and then things to match, it would also make it easier to
e.g. port it to a native C program.

  parent reply	other threads:[~2021-06-16 11:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 20:55 [BUG] question mark in GIT_SKIP_TESTS is broken in master Andrei Rybak
2021-06-15 23:28 ` [BUG] range expressions in GIT_SKIP_TESTS are broken in master (was [BUG] question mark in GIT_SKIP_TESTS is broken in master) Andrei Rybak
2021-06-16  3:28   ` Junio C Hamano
2021-06-16  4:12     ` Junio C Hamano
2021-06-16  8:29       ` Jeff King
2021-06-16  9:19         ` Junio C Hamano
2021-06-16  8:24     ` [PATCH] test-lib: fix "$remove_trash" regression and match_pattern_list() bugs Ævar Arnfjörð Bjarmason
2021-06-16  8:36       ` Jeff King
2021-06-16  9:22         ` Junio C Hamano
2021-06-16 10:23           ` Jeff King
2021-06-16 10:24             ` Jeff King
2021-06-16 11:38             ` Ævar Arnfjörð Bjarmason
2021-06-16 11:50               ` Jeff King
2021-06-17  0:29                 ` Junio C Hamano
2021-06-16  9:49         ` Ævar Arnfjörð Bjarmason [this message]
2021-06-16 11:43           ` Jeff King
2021-06-17  0:36           ` 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=87pmwmxd6f.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=rybak.a.v@gmail.com \
    /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).