Junio C Hamano <gitster@xxxxxxxxx> writes:
> If you found that an entry you read halfway has an inconsistent crc,
> and if you suspect that is because somebody else was writing to the
> same index, it is a _sure_ sign that you are not alone, and all the
> entries you read so far to the core, even if they weren't touched by
> that sombody else when you read them, may be stale, and worse yet,
> what you are going to read may be inconsistent with what you've read
> and have in-core (e.g. you may have read "f" before somebody else
> that is racing with you have turned it into a directory, and your
> next read may find "f/d" in the index without crc error).
The intention for v5 (admittedly this probably requires a lot more
documentation) was to only allow an in-place update in two cases:
* updating the data fields (*not* the name) of a file entry,
* adding or removing conflict entries at the end.
The latter probably requires a bit more thought to make it safe, too.
But I think the idea always was that any write that changes the basic
layout of the file (so that you would read something wrong) will need a
full rewrite. Otherwise we're too far in DB land. Most updates will be
of the "update the stat and/or sha1 of a file" kind, anyway.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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