summaryrefslogtreecommitdiff
path: root/compat
diff options
context:
space:
mode:
authorYiannis Marangos <yiannis.marangos@gmail.com>2014-04-10 21:31:21 +0300
committerJunio C Hamano <gitster@pobox.com>2014-04-10 12:27:58 -0700
commit426ddeead6112955dfb50ccf9bb4af05d1ca9082 (patch)
tree1ce356975572f79cc9c90f08217fe9a35d51c4af /compat
parent9aa91af0361e3c32fde5f8388dee963838308cd6 (diff)
downloadgit-426ddeead6112955dfb50ccf9bb4af05d1ca9082.tar.gz
read-cache.c: verify index file before we opportunistically update itym/fix-opportunistic-index-update-race
Before we proceed to opportunistically update the index (often done by an otherwise read-only operation like "git status" and "git diff" that internally refreshes the index), we must verify that the current index file is the same as the one that we read earlier before we took the lock on it, in order to avoid a possible race. In the example below git-status does "opportunistic update" and git-rebase updates the index, but the race can happen in general. 1. process A calls git-rebase (or does anything that uses the index) 2. process A applies 1st commit 3. process B calls git-status (or does anything that updates the index) 4. process B reads index 5. process A applies 2nd commit 6. process B takes the lock, then overwrites process A's changes. 7. process A applies 3rd commit As an end result the 3rd commit will have a revert of the 2nd commit. When process B takes the lock, it needs to make sure that the index hasn't changed since step 4. Signed-off-by: Yiannis Marangos <yiannis.marangos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat')
0 files changed, 0 insertions, 0 deletions