4fddad6558
When a hook script is not executable, Git will ignore its presence
in the hooks dir. To work around that, git-review checks the
downloaded commit-message hook to see whether it's executable and
then adjusts its permissions accordingly. This behavior has been
included since the initial release, but its naive implementation
wiped all existing permissions and then added only read and execute
for the file's owner (0o500/r-x------), leaving it set read-only.
This is overly-restrictive and can lead to minor annoyances when
deleting directories or for atypical multi-user and group ownership
scenarios due to ignoring the umask set for the process.
It is expected that, at this time, the described behavior is not
widely observed outside workflows which rely on fetching the hook
script over HTTP, as the SCP protocol preserves filesystem
permission flags from the source system, but it will have a much
broader impact in the future if git-review's default workflow shifts
away from SCP.
Replace the naive chmod implementation with one which adds execute
for anyone who already has read permission, but does not remove any
existing permissions, for example:
0o644/rw-r--r-- .. 0o755/rwx-r-xr-x
0o640/rw-r----- .. 0o750/rwx-r-x---
This new behavior should be more intuitive and less surprising for
users.
Change-Id: I48ac230df09bc802610cfef65bd9818c5b01673d
|
||
|---|---|---|
| .. | ||
| __init__.py | ||
| check_test_id_hashes.py | ||
| prepare.py | ||
| test_git_review.py | ||
| test_unit.py | ||
| utils.py | ||