summaryrefslogtreecommitdiff
path: root/Documentation/git-remote.txt
diff options
context:
space:
mode:
authorLibravatar Michael Haggerty <mhagger@alum.mit.edu>2017-08-21 13:51:34 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-08-23 10:37:21 -0700
commit4ff0f01cb7dd92fad49b4d0799590bb33a88168a (patch)
tree21b2a58187738108b9260301aed3f64640f9aca8 /Documentation/git-remote.txt
parentGit 2.14.1 (diff)
downloadtgif-4ff0f01cb7dd92fad49b4d0799590bb33a88168a.tar.xz
refs: retry acquiring reference locks for 100ms
The philosophy of reference locking has been, "if another process is changing a reference, then whatever I'm trying to do to it will probably fail anyway because my old-SHA-1 value is probably no longer current". But this argument falls down if the other process has locked the reference to do something that doesn't actually change the value of the reference, such as `pack-refs` or `reflog expire`. There actually *is* a decent chance that a planned reference update will still be able to go through after the other process has released the lock. So when trying to lock an individual reference (e.g., when creating "refs/heads/master.lock"), if it is already locked, then retry the lock acquisition for approximately 100 ms before giving up. This should eliminate some unnecessary lock conflicts without wasting a lot of time. Add a configuration setting, `core.filesRefLockTimeout`, to allow this setting to be tweaked. Note: the function `get_files_ref_lock_timeout_ms()` cannot be private to the files backend because it is also used by `write_pseudoref()` and `delete_pseudoref()`, which are defined in `refs.c` so that they can be used by other reference backends. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-remote.txt')
0 files changed, 0 insertions, 0 deletions