commit-graph.c: write non-split graphs as read-only
authorTaylor Blau <me@ttaylorr.com>
Wed, 29 Apr 2020 17:36:38 +0000 (11:36 -0600)
committerJunio C Hamano <gitster@pobox.com>
Wed, 29 Apr 2020 19:35:30 +0000 (12:35 -0700)
commit1f9becaedc9266651145a146fb63b84c3ee79d95
tree3fdfc50c09c11888f675c66edbc043a398604111
parentfa3bff2466ece4a10ba9beb9be3b45bada1c12eb
commit-graph.c: write non-split graphs as read-only

In the previous commit, Git learned 'hold_lock_file_for_update_mode' to
allow the caller to specify the permission bits (prior to further
adjustment by the umask and shared repository permissions) used when
acquiring a temporary file.

Use this in the commit-graph machinery for writing a non-split graph to
acquire an opened temporary file with permissions read-only permissions
to match the split behavior. (In the split case, Git uses
git_mkstemp_mode' for each of the commit-graph layers with permission
bits '0444').

One can notice this discrepancy when moving a non-split graph to be part
of a new chain. This causes a commit-graph chain where all layers have
read-only permission bits, except for the base layer, which is writable
for the current user.

Resolve this discrepancy by using the new
'hold_lock_file_for_update_mode' and passing the desired permission
bits.

Doing so causes some test fallout in t5318 and t6600. In t5318, this
occurs in tests that corrupt a commit-graph file by writing into it. For
these, 'chmod u+w'-ing the file beforehand resolves the issue. The
additional spot in 'corrupt_graph_verify' is necessary because of the
extra 'git commit-graph write' beforehand (which *does* rewrite the
commit-graph file). In t6600, this is caused by copying a read-only
commit-graph file into place and then trying to replace it. For these,
make these files writable.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit-graph.c
t/t5318-commit-graph.sh
t/t6600-test-reach.sh