From: Martin Ågren Date: Fri, 6 Oct 2017 20:12:12 +0000 (+0200) Subject: read-cache: drop explicit `CLOSE_LOCK`-flag X-Git-Tag: v2.16.0-rc0~183^2~2 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/812d6b00750b56fc4b6a75277a30c628cc7be2ef?hp=812d6b00750b56fc4b6a75277a30c628cc7be2ef 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 Signed-off-by: Junio C Hamano ---