sha1_file: do not leak `lock_file`
commitf132a127eebb8f1b14b87fc317ca68278fceb2e8
authorMartin Ågren <martin.agren@gmail.com>
Thu, 5 Oct 2017 20:32:03 +0000 (5 22:32 +0200)
committerJunio C Hamano <gitster@pobox.com>
Fri, 6 Oct 2017 01:07:10 +0000 (6 10:07 +0900)
treee5da266e43348b450313a6679f790623436cffdc
parentea220ee40cbb03a63ebad2be902057bf742492fd
sha1_file: do not leak `lock_file`

There is no longer any need to allocate and leak a `struct lock_file`.
Initialize it on the stack instead.

Before this patch, we set `lock = NULL` to signal that we have already
rolled back, and that we should not do any more work. We need to take
another approach now that we cannot assign NULL. We could, e.g., use
`is_lock_file_locked()`. But we already have another variable that we
could use instead, `found`. Its scope is only too small.

Bump `found` to the scope of the whole function and rearrange the "roll
back or write?"-checks to a straightforward if-else on `found`. This
also future-proves the code by making it obvious that we intend to take
exactly one of these paths.

Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c