lockfile.c: introduce 'hold_lock_file_for_update_mode'
commitfa3bff2466ece4a10ba9beb9be3b45bada1c12eb
authorTaylor Blau <me@ttaylorr.com>
Mon, 27 Apr 2020 16:27:58 +0000 (27 10:27 -0600)
committerJunio C Hamano <gitster@pobox.com>
Mon, 27 Apr 2020 18:27:36 +0000 (27 11:27 -0700)
tree1c5c1aa21de73e052d1f2127d5507de5450b9135
parentbef0413c3595acb469cc212792c12b7106048ddc
lockfile.c: introduce 'hold_lock_file_for_update_mode'

We use 'hold_lock_file_for_update' (and the '_timeout') variant to
acquire a lock when updating references, the commit-graph file, and so
on.

In particular, the commit-graph machinery uses this to acquire a
temporary file that is used to write a non-split commit-graph. In a
subsequent commit, an issue in the commit-graph machinery produces
graph files that have a different permission based on whether or not
they are part of a multi-layer graph will be addressed.

To do so, the commit-graph machinery will need a version of
'hold_lock_file_for_update' that takes the permission bits from the
caller.

Introduce such a function in this patch for both the
'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout'
functions, and leave the existing functions alone by inlining their
definitions in terms of the new mode variants.

Note that, like in the previous commit, 'hold_lock_file_for_update_mode'
is not guarenteed to set the given mode, since it may be modified by
both the umask and 'core.sharedRepository'.

Note also that even though the commit-graph machinery only calls
'hold_lock_file_for_update', that this is defined in terms of
'hold_lock_file_for_update_timeout', and so both need an additional mode
parameter here.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile.c
lockfile.h