Hi, A colleague of mine pointed out they had occasionally observed that some layers of a commit-graph chain appear to be have both read and write permission bits for the user, while others are marked as read-only. After some investigation, I realized that this only happens to the first layer in a commit-graph-chain, and occurs when we move a non-split graph into a chain as the new base. Since write_commit_graph() just renames in this case, we carry over the 0644 permissions that we create non-split graphs with, even though split graphs are created to be read-only. Initially, I resolved this by 'chmod(graph, 0444)'-ing the graph after renaming it into place, but it ends up being much cleaner if we introduce an additional parameter in 'hold_lock_file_for_update' for a mode. The first two patches set this up, and the third patch uses it in commit-graph.c, and corrects some test fallout. Eventually, we may want to take another look at all of this and always create lockfiles with permission 0444, but that change is much larger than this one and could instead be done over time. Thanks, Taylor Taylor Blau (3): tempfile.c: introduce 'create_tempfile_mode' lockfile.c: introduce 'hold_lock_file_for_update_mode' commit-graph.c: write non-split graphs as read-only commit-graph.c | 3 ++- lockfile.c | 18 ++++++++++-------- lockfile.h | 19 +++++++++++++++++-- t/t5318-commit-graph.sh | 11 ++++++++++- t/t6600-test-reach.sh | 2 ++ tempfile.c | 6 +++--- tempfile.h | 7 ++++++- 7 files changed, 50 insertions(+), 16 deletions(-) -- 2.26.1.108.gadb95c98e4
