Drop chmod from setup; hook ships executable
This commit is contained in:
@@ -9,10 +9,10 @@
|
||||
# Enable after cloning:
|
||||
#
|
||||
# git config core.hooksPath .githooks
|
||||
# chmod +x .githooks/commit-msg
|
||||
#
|
||||
# The Gitea web API cannot set the executable bit, so the chmod is required
|
||||
# on first clone even though the file is committed.
|
||||
# The executable bit is committed (mode 100755), so a clone gets a runnable
|
||||
# hook. Git still will not enable a repo's hooks on its own — deliberately, so
|
||||
# that cloning cannot execute code from the remote — hence the one command.
|
||||
|
||||
msg_file="$1"
|
||||
|
||||
|
||||
@@ -139,5 +139,6 @@ Nothing about the format is bot-specific. Fetch the JSON and use it however you
|
||||
## Note on history
|
||||
|
||||
Commits here carry no AI attribution — see [`.githooks/commit-msg`](.githooks/commit-msg),
|
||||
enabled with `git config core.hooksPath .githooks && chmod +x .githooks/commit-msg`.
|
||||
Please keep it that way in PRs.
|
||||
enabled with `git config core.hooksPath .githooks` after cloning. The hook ships
|
||||
executable; Git just never turns a repo's hooks on by itself. Please keep it that
|
||||
way in PRs.
|
||||
|
||||
Reference in New Issue
Block a user