Yiannis Marangos <yiannis.maran...@gmail.com> writes:

> process A calls git-rebase
> process A applies the 1st commit
> process B calls git-status
> process B calls read_cache()
> process A applies the 2nd commit
> process B holds the index.lock
> process B writes back the old index (the one that was read from read_cache())
> process A applies the 3rd commit (now the 3rd commit contains also a revert 
> of the 2nd)

The above sequence shows we are clearly doing it wrong.  B's taking
of the lock is not protecting anything from anybody.

We try minimizing the lock contention by delaying the taking of the
lock by B, but even if we leave it at the current location in the
above sequence, at least B must verify that the contents of the
index it just took the lock on still matches what it read with its
earlier call to read_cache(), which would make it pretend as if it
took the lock before it did read_cache(), before writing the
refreshed results back.

I think we have a checksum for the entire index file at the end, so
one fix might be to teach read_index_from() to read that and store
it in a new field in "struct index_state", and then make the
"opportunistic update" codepath to verify that the index on the
filesystem still has the same checksum.
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

Reply via email to