Post-receive hook versus client-side watch: minimizing push-only notification noise

Answer

Use a server-side post-receive hook. It fires exactly once per successful push and remains silent for fetches, rebases, git gc, or any local operation.

Confirmed facts

• A post-receive hook runs on the remote after the refs are updated; it does not run for fetch, clone, rebase, or maintenance commands.
• If a pre-receive hook rejects the push or the server refuses a force‑push, no refs are updated and the post-receive hook is not invoked – which matches the desired silence.
• The undocumented variable GIT_NOTIFY_SILENT is not part of Git’s stability guarantee; its behavior changes between versions (2.35‑2.42) and should not be relied upon.
• Client‑side watchers cannot distinguish the cause of ref changes; they fire on every fetch, rebase, or repack, producing false positives unless you add complex diffing logic, which re‑introduces noise and misses pushes made by others between polls.
• A hybrid approach (server hook + client filter) adds no benefit because the server hook already has zero false positives by construction.

Steps to implement a reliable single‑alert hook

1. Log in to the Git server with sufficient privileges to add hooks.
2. Navigate to the repository’s $GIT_DIR/hooks directory (e.g., /srv/git/myproject.git/hooks).
3. Create a file named post-receive with the following content:

#!/bin/sh
# post-receive hook: send one notification per push
logger -t git-post-receive "Push received: $(cat)"
# Replace the logger line with your actual alert method (email, webhook, etc.)

1. Make the script executable: chmod +x hooks/post-receive
2. Test:
1. Push one or more branches: git push origin main feature – verify exactly one log entry appears.
2. Run git fetch, git rebase, git gc against the same remote – confirm no new log entries.
3. If you have a pre-receive hook that can reject pushes, trigger a rejection and ensure no notification is emitted.

Missing diagnostic detail

Do you have administrative access to install hooks on the remote repository? If not, you must rely on the hosting provider’s push webhook or events API, which provides the same once‑per‑push semantics.