summaryrefslogtreecommitdiff
path: root/apply.c
diff options
context:
space:
mode:
authorMartin Ågren <martin.agren@gmail.com>2018-05-09 20:55:38 (GMT)
committerJunio C Hamano <gitster@pobox.com>2018-05-10 05:54:45 (GMT)
commitb227586831ed393e1d60629bfedcef01be4b9c22 (patch)
treec58f4d54e1818bf4969d77840f47e893cee7b4de /apply.c
parent3c6fad4a3fcc9a01dd3d9678360907271ad85920 (diff)
downloadgit-b227586831ed393e1d60629bfedcef01be4b9c22.zip
git-b227586831ed393e1d60629bfedcef01be4b9c22.tar.gz
git-b227586831ed393e1d60629bfedcef01be4b9c22.tar.bz2
lock_file: make function-local locks non-static
Placing `struct lock_file`s on the stack used to be a bad idea, because the temp- and lockfile-machinery would keep a pointer into the struct. But after 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we can safely have lockfiles on the stack. (This applies even if a user returns early, leaving a locked lock behind.) These `struct lock_file`s are local to their respective functions and we can drop their staticness. For good measure, I have inspected these sites and come to believe that they always release the lock, with the possible exception of bailing out using `die()` or `exit()` or by returning from a `cmd_foo()`. As pointed out by Jeff King, it would be bad if someone held on to a `struct lock_file *` for some reason. After some grepping, I agree with his findings: no-one appears to be doing that. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'apply.c')
-rw-r--r--apply.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/apply.c b/apply.c
index 134dc7b..3d43212 100644
--- a/apply.c
+++ b/apply.c
@@ -4058,7 +4058,7 @@ static int build_fake_ancestor(struct apply_state *state, struct patch *list)
{
struct patch *patch;
struct index_state result = { NULL };
- static struct lock_file lock;
+ struct lock_file lock = LOCK_INIT;
int res;
/* Once we start supporting the reverse patch, it may be