Zygo Blaxell [off-list ref] writes:
As far as I can tell, the index doesn't handle this case at all.
...
racy-git.txt doesn't discuss concurrent modification of files with the
index. It only discusses low-resolution file timestamps and modifications
at times that are close to, but not concurrent with, index modifications.
Correct. As I said a few times in this thread, a use case with concurrent
modifications is outside of the original design scope of git.
As you may have realized, racy-git solution actually _relies_ on lack of
concurrent modifications. The document does not even _talk_ about this
assumption, exactly because at least back then it was a common knowledge
shared by everybody that users are not supposed to muck with files in the
work tree until they get control back from git and they can keep both
halves if they get a new broken loose object if they did so ;-).