Zygo Blaxell <zblaxell@xxxxxxxxxxxxxxxxxxxx> 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html