Client-side vs server-side hooks in Git - Performance Comparison
We want to understand how the time it takes to run Git hooks changes as the number of commits or pushes grows.
Which hook type--client-side or server-side--scales better with more activity?
Analyze the time complexity of these Git hook examples.
# Client-side pre-commit hook example
#!/bin/sh
files=$(git diff --cached --name-only)
for file in $files; do
# Run lint check on each file
lint-check "$file"
done
# Server-side pre-receive hook example
#!/bin/sh
while read oldrev newrev refname; do
# Run tests on the pushed commits
run-tests "$oldrev" "$newrev"
done
The client-side hook checks each changed file before commit. The server-side hook checks all commits in a push.
Look for loops or repeated checks in the hooks.
- Primary operation: Loop over changed files (client-side) or commits (server-side).
- How many times: Number of changed files in commit or number of commits in push.
More changed files or commits mean more checks.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 files/commits | 10 lint or test runs |
| 100 files/commits | 100 lint or test runs |
| 1000 files/commits | 1000 lint or test runs |
Pattern observation: The time grows directly with the number of files or commits checked.
Time Complexity: O(n)
This means the time to run hooks grows linearly with the number of files or commits processed.
[X] Wrong: "Hooks always run instantly no matter how many files or commits there are."
[OK] Correct: Each file or commit adds work, so more changes mean more time spent running hooks.
Understanding how hook execution time grows helps you design efficient workflows and avoid slowdowns as projects grow.
"What if the client-side hook ran checks only on staged files instead of all changed files? How would the time complexity change?"