summaryrefslogtreecommitdiff
path: root/bundle.c
diff options
context:
space:
mode:
authorMartin Ågren <martin.agren@gmail.com>2018-05-09 22:55:38 +0200
committerJunio C Hamano <gitster@pobox.com>2018-05-10 14:54:45 +0900
commitb227586831ed393e1d60629bfedcef01be4b9c22 (patch)
treec58f4d54e1818bf4969d77840f47e893cee7b4de /bundle.c
parent3c6fad4a3fcc9a01dd3d9678360907271ad85920 (diff)
downloadgit-b227586831ed393e1d60629bfedcef01be4b9c22.tar.gz
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 'bundle.c')
-rw-r--r--bundle.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/bundle.c b/bundle.c
index efe547e25f..4fde31d210 100644
--- a/bundle.c
+++ b/bundle.c
@@ -409,7 +409,7 @@ static int write_bundle_refs(int bundle_fd, struct rev_info *revs)
int create_bundle(struct bundle_header *header, const char *path,
int argc, const char **argv)
{
- static struct lock_file lock;
+ struct lock_file lock = LOCK_INIT;
int bundle_fd = -1;
int bundle_to_stdout;
int ref_count = 0;