"Neeraj Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > +core.fsync:: > + A comma-separated list of parts of the repository which should be > + hardened via the core.fsyncMethod when created or modified. You can > + disable hardening of any component by prefixing it with a '-'. Later > + items take precedence over earlier ones in the list. For example, > + `core.fsync=all,-pack-metadata` means "harden everything except pack > + metadata." Items that are not hardened may be lost in the event of an > + unclean system shutdown. > ++ > +* `none` disables fsync completely. This must be specified alone. > +* `loose-object` hardens objects added to the repo in loose-object form. > +* `pack` hardens objects added to the repo in packfile form. > +* `pack-metadata` hardens packfile bitmaps and indexes. > +* `commit-graph` hardens the commit graph file. > +* `objects` is an aggregate option that includes `loose-objects`, `pack`, > + `pack-metadata`, and `commit-graph`. > +* `default` is an aggregate option that is equivalent to `objects,-loose-object` > +* `all` is an aggregate option that syncs all individual components above. I am not quite sure if this is way too complex (e.g. what does it mean that we do not care much about loose-object safety while we do care about commit-graph files?) and at the same time it is too limited (e.g. if it makes sense to say a class of items deserve more protection than another class of items, don't we want to be able to say "class X is ultra-precious so use method A on them, while class Y is mildly precious and use method B on them, everything else are not that important and doing the default thing is just fine"). If we wanted to allow the "matrix" kind of flexibility, I think the way to do so would be fsync.<class>.method = <value> e.g. [fsync "default"] method = none [fsync "loose-object"] method = fsync [fsync "pack-metadata"] method = writeout-only Where do we expect users to take the core.fsync settings from? Per repository? If it is from per user (i.e. $HOME/.gitconfig), do people tend to share it across systems (not necessarily over NFS) with the same contents? If so, I am not sure if fsync.method that is way too close to the actual "implementation" is a good idea to begin with. From end-user's point of view, it may be easier to express "class X is ultra-precious, and class Y and Z are mildly so", with something like fsync.<class>.level = <how-precious> and let the Git implementation on each platform choose the appropriate fsync method to protect the stuff at that precious-ness. Thanks.
