Re: [PATCH] tests: disable fsync everywhere
- From
- Eric Wong <e@80x24.org>
- Date
- Oct 29, 2021, 07:56 UTC
- Message-ID
- <20211029075640.M183252@dcvr>
- In-Reply-To
- <xmqqr1c4mmsf.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Eric Wong <e@80x24.org> writes:
> > +# n.b. consider using Git.pm
> > +sub use_fsync {
> > + if (!defined($_use_fsync)) {
> > + my $x = $ENV{GIT_TEST_FSYNC};
> > + if (defined $x) {
>
> I would have expected to see "exists $ENV{GIT_TEST_FSYNC}", but I
> guess there is no way to place in %ENV anyway, so it would be OK.Was that meant to say: "no way to place `undef' in %ENV anyway"?
If so, `undef' can actually be in Perl's %ENV, though it appears to get coerced into "" (empty string) when spawning processes.
Show 9 quoted lines
> > + local $ENV{GIT_CONFIG};
> > + delete $ENV{GIT_CONFIG};
>
> OK, "git -c test.fsync=no cvsserver" would added something to
> GIT_CONFIG that would affect test.fsync, but wouldn't the usual
> last-one-wins rule be sufficient to check the value of $x using the
> next construction, no matter what is in GIT_CONFIG? I do not think
> it would hurt to delete $ENV{GIT_CONFIG}, but I am not sure how it
> is necessary.Leaving GIT_CONFIG set was actually causing "git config" to exit(1) since git-cvsserver sets GIT_CONFIG and the GIT_CONFIG file doesn't have a test.fsync setting. This is the current behavior, I think it's a weird quirk, but intended behavior of git-config.
# this assumes you don't have foo.bar set in your ~/.gitconfig :> $ GIT_CONFIG=$HOME/.gitconfig git -c foo.bar=0 config --type=bool foo.bar $ echo $? 1
> > + my $v = ::safe_pipe_capture('git', '-c', "test.fsync=$x",
> > + qw(config --type=bool test.fsync));
>
> THis is an interesting idiom.Heh, I just thought of it before sending my original. I was going to use a regexp originally (in git-svn, too), but didn't want to get into corner cases such as hex and +/- prefixes).
Show 13 quoted lines
> > + $_use_fsync = defined($v) ? ($v eq "true\n") : 1;
> > + }
> > + }
> > + $_use_fsync;
> > +}
>
>
> > +# TODO: move this to Git.pm?
> > +sub use_fsync {
>
> Possibly, but in a slightly more general form, taking the name of
> the environment variable that holds a boolean value as an argument,
> or something?Yeah. It would've been more useful if git-cvsserver used Git.pm; but I didn't want to introduce Git.pm into git-cvsserver in case somebody relies on git-cvsserver being standalone.