The main issue is that non-expert users might not realize that they
really need to run "git fsck" after a crash; otherwise, what might
happen is that although git is only appending, that you might have
some zero-length (or partially written) git object or pack files, and
while you might not notice at that moment, it might come and bite you
later. If you do try to recover immediately after a crash, in the
worst case you might have to do that "git am -s /tmp/mbox-filled-with
patches" command, but otherwise you won't lose much data.
So perhaps one alternative strategy to calling fsync(2) after every
single git object file write might be to have git create a zero-length
".git/in-progress-<pid>" file, which gets fsync'ed, and then it can do
the "git am -s /tmp/akpm-big-bag-o-patches" processing nice and fast,
and once git is done, then we call call sync(2) and then delete the
in-progress file.
If there is an in-progress file in the .git directory, git would then
automatically run git fsck to make sure the repository is consistent.
For people who care, maybe that's a good compromise. (Me, the way
things are right now is just fine since I have a nice fast SSD, and so
setting fsyncObjectfiles is a perfectly fine thing as far as I am
concerned. :-)
- Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
