On Fri, Aug 10, 2012 at 7:13 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > By the way, you can only detect such inconsistency when you are > lucky enough that you catch the other person in the middle of > writing. > > If the index you are looking at holds a large tree with very many > paths, it is possible that there are two large directories, and > after you read all entries from one, the other process starts > modifying the paths in that directory, without you ever finding it > out. If the goal of the topic is to make the index work better in > projects with large trees, it may be wise to think about locking the > whole thing, so that you do not have to rely on the per-entry crc > and you being lucky to detect such a race. The per-entry crc, as > far as I understand, may have been introduced primarily to detect > on-disk data corruption; it is not a suitable mechanism to detect > conflicting accesses. So we acquire the lock just before we need to write, or at the time we open for reading? -- Duy -- 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