Re: [RFC PATCH 2/2] core.fsyncObjectFiles: make the docs less flippant

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

quoted

When I saw the subject in my mailbox, I expected to see that you
would resurrect Christoph's updated text in [*1*], but you wrote a
whole lot more ;-) And they are quite informative to help readers to
understand what the option does.  I am not sure if the understanding
directly help readers to decide if it is appropriate for their own
repositories, though X-<.

I agree that it is an improvement, and am therefore in favor of applying
the patch.

Just the improved docs, or flipping the default of core.fsyncObjectFiles
to "true"?

I am not Dscho, but "applying THE patch" meant, at least to me, the
patch [2/2] to the docs, which was the message we are responding to.

I've been meaning to re-roll this. I won't have time anytime soon to fix
git's fsync() use, i.e. ensure that we run up & down modified
directories and fsync()/fdatasync() file/dir fd's as appropriate but I
think documenting it and changing the core.fsyncObjectFiles default
makes sense and is at least a step in the right direction.

I do think it makes more sense for a v2 to split most of this out into
some section that generally discusses data integrity in the .git
directory. I.e. that says that currently where we use fsync() (such as
pack/commit-graph writes) we don't fsync() the corresponding
director{y,ies), and ref updates don't fsync() at all.

Yes, I think all of these are sensible things to do sometime in the
future.

Where to put that though? gitrepository-layout(5)? Or a new page like
gitrepository-integrity(5) (other suggestions welcome..).

I do not have a good suggestion at this moment on this.