summaryrefslogtreecommitdiff
path: root/remote-curl.c
diff options
context:
space:
mode:
authorMichael Haggerty <mhagger@alum.mit.edu>2015-05-11 10:35:26 (GMT)
committerJunio C Hamano <gitster@pobox.com>2015-05-14 21:51:51 (GMT)
commitf4ab4f3ab117cf375ae7bb8908c7b5ad687342b1 (patch)
treeb24e6af2887c9c5f8b2904bf46e47cdb7d7b4cdc /remote-curl.c
parent044b6a9efecf9941073b99ced4cb2881b18aee62 (diff)
downloadgit-f4ab4f3ab117cf375ae7bb8908c7b5ad687342b1.zip
git-f4ab4f3ab117cf375ae7bb8908c7b5ad687342b1.tar.gz
git-f4ab4f3ab117cf375ae7bb8908c7b5ad687342b1.tar.bz2
lock_packed_refs(): allow retries when acquiring the packed-refs lock
Currently, there is only one attempt to acquire any lockfile, and if the lock is held by another process, the locking attempt fails immediately. This is not such a limitation for loose reference files. First, they don't take long to rewrite. Second, most reference updates have a known "old" value, so if another process is updating a reference at the same moment that we are trying to lock it, then probably the expected "old" value will not longer be valid, and the update will fail anyway. But these arguments do not hold for packed-refs: * The packed-refs file can be large and take significant time to rewrite. * Many references are stored in a single packed-refs file, so it could be that the other process was changing a different reference than the one that we are interested in. Therefore, it is much more likely for there to be spurious lock conflicts in connection to the packed-refs file, resulting in unnecessary command failures. So, if the first attempt to lock the packed-refs file fails, continue retrying for a configurable length of time before giving up. The default timeout is 1 second. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'remote-curl.c')
0 files changed, 0 insertions, 0 deletions