Patrick Steinhardt <ps@xxxxxx> writes: >> How about doing a series to unconditionally sync loose ref creation >> and modification? >> >> Alternatively, we could link it to the existing configuration to >> control synching of object files. >> >> I do not think core.fsyncObjectFiles having "object" in its name is >> a good reason not to think those who set it to true only care about >> the loose object files and nothing else. It is more sensible to >> consider that those who set it to true cares about the repository >> integrity more than those who set it to false, I would think. >> >> But that (i.e. doing it conditionally and choose which knob to use) >> is one extra thing that needs justification, so starting from >> unconditional fsync_or_die() may be the best way to ease it in. > > I'd be happy to revive my old patch series, but this kind of depends on > where we're standing with the other patch series by Neeraj. If you say > that we'll likely not land his patch series for the upcoming release, > but a small patch series which only starts to sync loose refs may have a > chance, then I'd like to go down that path as a stop-gap solution. > Otherwise it probably wouldn't make a lot of sense. The above was what I wrote before the revived series from Neeraj. Now I've seen it, and more importantly, the most recent one from you on top of that to add ref hardening as a new "component" or two, I like the overall shape of the end result (except for the semantics implemented by the configuration parser, which can be fixed without affecting how the hardening components are implemented). Hopefully the base series of Neeraj can be solidified soon enough to make it unnecessary for a stop-gap measure. We'll see. Thanks.
