summaryrefslogtreecommitdiff
path: root/builtin-fetch.c
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2007-09-14 03:31:16 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2007-09-19 03:22:30 -0700
commit106764e6515dd0fb9fda8bb8cab523932ae903b3 (patch)
tree498d678d97b6c1a4aabdb3ddc1cb6854382ef8be /builtin-fetch.c
parentSimplify fetch transport API to just one function (diff)
downloadtgif-106764e6515dd0fb9fda8bb8cab523932ae903b3.tar.xz
Refactor index-pack "keep $sha1" handling for reuse
There is a subtle (but important) linkage between receive-pack and index-pack that allows index-pack to create a packfile but protect it from being deleted by a concurrent `git repack -a -d` operation. The linkage works by having index-pack mark the newly created pack with a ".keep" file and then it passes the SHA-1 name of that new packfile to receive-pack along its stdout channel. The receive-pack process must unkeep the packfile by deleting the .keep file, but can it can only do so after all elgible refs have been updated in the receiving repository. This ensures that the packfile is either kept or its objects are reachable, preventing a concurrent repacker from deleting the packfile before it can determine that its objects are actually needed by the repository. The new builtin-fetch code needs to perform the same actions if it choose to run index-pack rather than unpack-objects, so I am moving this code out to its own function where both receive-pack and fetch-pack are able to invoke it when necessary. The caller is responsible for deleting the returned ".keep" and freeing the path if the returned path is not NULL. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin-fetch.c')
0 files changed, 0 insertions, 0 deletions