Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>> 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.
