Duy Nguyen <pclouds@xxxxxxxxx> writes:
> ... I know the
> "index_file" in prepare_to_commit() is probably "index.lock" or
> something, but that does not stop us from locking again
> ("index.lock.lock") if we want to update it.
We grabbed the lock on the real index and we have written out the
result of "update-index --refresh" to it (and closed), but we still
want to and do keep the lock while "add -i" works on it. And then
after "add -i" returns, we still have the lock on the real index and
the patch wants to write to it again to store the refreshed cache-tree
under that lock.
It may be the case that the API suite currently lacks a way to allow
the caller to reopen the same "index.lock" file after calling
write-locked-index(CLOSE_LOCK), and taking a lock on "index.lock" to
write into "index.lock.lock" and renaming it to "index.lock" could
be a workaround for it, but doesn't that sound a wrong workaround?
--
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