Re: [PATCH v4 4/4] cache-tree: Write updated cache-tree after commit
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 8, 2014, 18:32 UTC
- Message-ID
- <xmqqfvibaegr.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CACsJy8C20oFdATHKTLK=9U3_kHu1QsuS4i74RPgQn0aTwVCC8w@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> 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?