On Thu, Mar 10, 2022 at 3:35 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Neeraj K. Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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 Thanks for reporting this. I didn't see a failure in CI, nor when running that specific test in mingw. I also munged my config to include core.fsyncObjectFiles and didn't see a failure. Could you please share some more verbose output of the test, so I can look a bit deeper? In parallel, I'm trying again after merging my changes onto seen. Thanks, Neeraj
