Re: [PATCH v6 0/6] A design for future-proofing fsync() configuration

[Junio C Hamano <gitster@pobox.com>]

"Neeraj K. Singh via GitGitGadget" <gitgitgadget@gmail.com> writes:

> After this change, new persistent data files added to the repo will need to
> be added to the fsync_component enum and documented in the
> Documentation/config/core.txt text.
>
> V6 changes:
>
>  * Move only the windows csprng includes into wrapper.c rather than all of
>    them. This fixes the specific build issue due to broken Windows headers.
>    [6]
>  * Split the configuration parsing of core.fsync from the mechanism to focus
>    the review.
>  * Incorporate Patrick's patch at [7] into the core.fsync mechanism patch.
>  * Pick the stricter one of core.fsyncObjectFiles and (fsync_components &
>    FSYNC_COMPONENT_LOOSE_OBJECTS), to respect the older setting.
>  * Issue a deprecation warning but keep parsing and honoring
>    core.fsyncObjectFiles.
>  * Change configuration parsing of core.fsync to always start with the
>    platform default. none resets to the empty set. The comma separated list
>    implies a set without regards to ordering now. This follows Junio's
>    suggestion in [8].
>  * Change the documentation of the core.fsync option to reflect the way the
>    new parsing code works.

Hmph, this seems to make one test fail.

t5801-remote-helpers.sh (Wstat: 256 Tests: 31 Failed: 4)
  Failed tests:  14-16, 31
    Non-zero exit status: 1
Files=1, Tests=31,  2 wallclock secs ( 0.04 usr  0.00 sys + 1.40 cusr  1.62 csys =  3.06 CPU)
Result: FAIL