diff options
author | Taylor Blau <me@ttaylorr.com> | 2020-04-29 11:36:38 -0600 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-04-29 12:35:30 -0700 |
commit | 1f9becaedc9266651145a146fb63b84c3ee79d95 (patch) | |
tree | 3fdfc50c09c11888f675c66edbc043a398604111 /t/t5100/msg0013 | |
parent | lockfile.c: introduce 'hold_lock_file_for_update_mode' (diff) | |
download | tgif-1f9becaedc9266651145a146fb63b84c3ee79d95.tar.xz |
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>
Diffstat (limited to 't/t5100/msg0013')
0 files changed, 0 insertions, 0 deletions