]> git.ipfire.org Git - thirdparty/git.git/commit - builtin/commit.c
read-cache: drop explicit `CLOSE_LOCK`-flag
authorMartin Ågren <martin.agren@gmail.com>
Fri, 6 Oct 2017 20:12:12 +0000 (22:12 +0200)
committerJunio C Hamano <gitster@pobox.com>
Sat, 7 Oct 2017 01:20:56 +0000 (10:20 +0900)
commit812d6b00750b56fc4b6a75277a30c628cc7be2ef
tree32eff5a9b675cf7555b44d19565ae08e921994f2
parent8dc3834610b676c2eb64cfe2a08b8b3d05be05df
read-cache: drop explicit `CLOSE_LOCK`-flag

`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the same as `CLOSE_LOCK`, which seems like a bug.

We might feel tempted to restructure the code in order to close the file
later, or conditionally. It also feels a bit unfortunate that we simply
"happen" to close the lock by way of an implementation detail of
lockfiles. But note that we need to close the temporary file before
`stat`-ing it, at least on Windows. See 9f41c7a6b (read-cache: close
index.lock in do_write_index, 2017-04-26).

Drop `CLOSE_LOCK` and make it explicit that `write_locked_index()`
always closes the lock. Whether it is also committed is governed by the
remaining flag, `COMMIT_LOCK`.

This means we neither have nor suggest that we have a mode to write the
index and leave the file open. Whatever extra contents we might
eventually want to write, we should probably write it from within
`write_locked_index()` itself anyway.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/commit.c
cache.h
read-cache.c