pre-push hook in Git - Time & Space Complexity

Time Complexity: pre-push hook

O(n)

Understanding Time Complexity

We want to understand how the time taken by a git pre-push hook changes as the amount of work it does grows.

Specifically, how does the hook's execution time grow when it checks many files or runs many commands before pushing?

Scenario Under Consideration

Analyze the time complexity of the following pre-push hook script.

#!/bin/sh
# pre-push hook example

while read local_ref local_sha remote_ref remote_sha ; do
   git diff --name-only $local_sha $remote_sha | while read file ; do
     echo "Checking $file"
     # simulate check command
   done
 done

This hook reads refs being pushed, then lists changed files and checks each one before allowing the push.

Identify Repeating Operations

• Primary operation: Loop over changed files to check each one.
• How many times: Once per changed file in the push.

How Execution Grows With Input

As the number of changed files increases, the hook runs more checks, so time grows roughly in direct proportion.

Input Size (n)	Approx. Operations
10 changed files	10 checks
100 changed files	100 checks
1000 changed files	1000 checks

Pattern observation: The time grows linearly with the number of changed files.

Final Time Complexity

Time Complexity: O(n)

This means the hook's running time increases directly with the number of files it checks before pushing.

Common Mistake

[X] Wrong: "The hook always runs in constant time no matter how many files change."

[OK] Correct: The hook checks each changed file one by one, so more files mean more work and longer time.

Interview Connect

Understanding how hooks scale helps you write efficient checks that keep your code safe without slowing down your workflow too much.

Self-Check

"What if the hook ran a single command that checked all files at once instead of one by one? How would the time complexity change?"

Practice

1. What is the main purpose of a pre-push hook in Git?

easy

A. To delete local branches after pushing

B. To merge branches automatically before pushing

C. To run checks or tests before code is pushed to a remote repository

D. To create a backup of the repository before pushing

Solution

1. Step 1: Understand the role of pre-push hooks

   Pre-push hooks run scripts before pushing code to a remote repository to catch errors early.

2. Step 2: Identify the correct purpose

   They help ensure code quality by running tests or checks before the push happens.

3. Final Answer:

   To run checks or tests before code is pushed to a remote repository -> Option C

4. Quick Check:

   Pre-push hook = run checks before push [OK]

Hint: Pre-push hooks run before push to catch problems early [OK]

Common Mistakes:

• Confusing pre-push with post-push hooks
• Thinking it merges branches automatically
• Assuming it deletes branches

2. Which of the following is the correct way to make a pre-push hook script executable on Linux or macOS?

easy

A. chmod +x .git/hooks/pre-push

B. git enable pre-push

C. chmod 777 .git/hooks/pre-push

D. git hook activate pre-push

Solution

1. Step 1: Identify how to make scripts executable

   On Linux/macOS, chmod +x sets execute permission on a file.

2. Step 2: Apply to pre-push hook

   Running chmod +x .git/hooks/pre-push makes the hook script runnable by Git.

3. Final Answer:

   chmod +x .git/hooks/pre-push -> Option A

4. Quick Check:

   Make hook executable = chmod +x [OK]

Hint: Use chmod +x to make hook scripts executable [OK]

Common Mistakes:

• Using git commands that don't exist for hooks
• Setting overly permissive permissions like 777
• Forgetting to make the script executable

3. Given this pre-push hook script snippet, what will happen if the tests fail?

#!/bin/sh
npm test || exit 1

medium

A. The push will continue regardless of test results

B. The script will delete the remote branch

C. The tests will be skipped

D. The push will be blocked and stopped

Solution

1. Step 1: Understand the script logic

   The script runs npm test. If tests fail, npm test returns non-zero, triggering exit 1.

2. Step 2: Effect of exit 1 in pre-push hook

   Exiting with a non-zero code stops the push process, blocking the push.

3. Final Answer:

   The push will be blocked and stopped -> Option D

4. Quick Check:

   Exit 1 in pre-push = block push [OK]

Hint: Exit non-zero in pre-push stops the push [OK]

Common Mistakes:

• Assuming push continues even if tests fail
• Thinking tests are skipped automatically
• Confusing exit codes with success

4. You wrote a pre-push hook script but it does not run when you push. What is the most likely cause?

medium

A. The remote repository is down

B. The script is missing execute permissions

C. You forgot to commit your changes

D. The branch name is incorrect

Solution

1. Step 1: Check script execution requirements

   Git requires hook scripts to have execute permission to run them.

2. Step 2: Identify common cause of hook not running

   If the script lacks execute permission, Git silently skips running it.

3. Final Answer:

   The script is missing execute permissions -> Option B

4. Quick Check:

   Missing execute permission = hook won't run [OK]

Hint: Check execute permission if hook doesn't run [OK]

Common Mistakes:

• Blaming remote repository for local hook issues
• Thinking commit status affects hook execution
• Assuming branch name affects hook running

5. You want your pre-push hook to run tests only on files changed in the last commit before pushing. Which approach is best?

hard

A. Use git diff --name-only HEAD~1 HEAD inside the hook to get changed files and run tests accordingly

B. Run tests on all files every time without checking changes

C. Manually list files in the hook script each time

D. Push first, then run tests on the remote repository

Solution

1. Step 1: Identify how to detect changed files

   The command git diff --name-only HEAD~1 HEAD lists files changed in the last commit.

2. Step 2: Use this command in pre-push hook

   Using this inside the hook lets you run tests only on changed files, saving time and resources.

3. Final Answer:

   Use git diff --name-only HEAD~1 HEAD inside the hook to get changed files and run tests accordingly -> Option A

4. Quick Check:

   Detect changed files with git diff for selective tests [OK]

Hint: Use git diff to find changed files for selective tests [OK]

Common Mistakes:

• Running tests on all files unnecessarily
• Manually updating file lists each time
• Running tests after push instead of before