# Re: \[PATCH v3 6/6\] core.fsyncobjectfiles: enable batch mode for testing

- List: git
- 1 message, 1 author
- Page: https://ratatoskr.run/git/2021/09/7902656/t

## Re: \[PATCH v3 6/6\] core.fsyncobjectfiles: enable batch mode for testing

- From: Junio C Hamano \<hidden\>
- Date: 2021-09-16 06:19:28 
- Message: https://ratatoskr.run/git/2021/09/7902656.md

```text
Junio C Hamano [ref] writes:

> Neeraj Singh [ref] writes:
>
>> This commit is mainly to ensure that we get coverage of batch mode on all
>> platforms in the CI infrastructure.  I don't believe it should be included in
>> mainline git without significantly more discussion and experimentation.
>
> Am I incorrect to say that only just a handful of code paths can
> take advantage of the bulk checkin "plugging-unplugging" feature to
> begin with, so running _all_ the existing tests that cover
> everything with this core.fsyncobjectfiles=batch setting is rather
> pointless?
>
> If so, perhaps instead of 6/6, you should identify key code paths
> that would be affected by this feature (perhaps "git add" is one of
> them), and either write a new test script dedicated for this feature
> or piggy-back on existing test scripts that already tests the code
> paths and adding new test pieces there that exercise this new feature.
>
> If it is a good idea to run all the tests with core.fsyncobjectfiles
> set to batch, however, it probalby is easiest to invent a new
> environment variable GIT_TEST_FORCE_CORE_FSYNCOBJECTFILES and have
> it honored as the default when it is set, and add a NEW CI job that
> exports the environment with the value "batch".  

I have to take a part of this back.  A new environment variable that
is honored in the absense of core.fsyncobjectfiles would be needed
if you need to run all tests, but you do not necessarily have to add
a new CI job---instead you should be able to piggyback on an
existing job, by mimicking the way how ci/run-build-and-tests.sh
enables various test options on one of the jobs.

> Other people
> (including the ones from Microsoft, I think) are much more familiar
> than I am on how to make this kind of thing work in GitHub Actions.

This part still stands ;-)  There might be a better way than adding
yet another environment variable.

```