summaryrefslogtreecommitdiff
path: root/contrib/gitview
diff options
context:
space:
mode:
authorLibravatar Yiannis Marangos <yiannis.marangos@gmail.com>2014-04-10 21:31:21 +0300
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-04-10 12:27:58 -0700
commit426ddeead6112955dfb50ccf9bb4af05d1ca9082 (patch)
tree1ce356975572f79cc9c90f08217fe9a35d51c4af /contrib/gitview
parentwrapper.c: add xpread() similar to xread() (diff)
downloadtgif-426ddeead6112955dfb50ccf9bb4af05d1ca9082.tar.xz
read-cache.c: verify index file before we opportunistically update it
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 'contrib/gitview')
0 files changed, 0 insertions, 0 deletions