Squashing commits in Git - Time & Space Complexity
When we squash commits in git, we combine multiple changes into one. Understanding how the time to squash grows helps us know what to expect as the number of commits increases.
We want to answer: How does the effort to squash commits change as we have more commits?
Analyze the time complexity of the following git commands used to squash commits.
git rebase -i HEAD~5
# In the editor, mark commits to squash
# Save and close editor
# Git rewrites commit history combining commits
This snippet shows an interactive rebase to squash the last 5 commits into one.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Git processes each commit in the range one by one during the rebase.
- How many times: Once per commit in the selected range (e.g., 5 commits means 5 steps).
As the number of commits to squash increases, git must process each commit individually to combine them.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 commits | Processes 10 commits sequentially |
| 100 commits | Processes 100 commits sequentially |
| 1000 commits | Processes 1000 commits sequentially |
Pattern observation: The work grows directly with the number of commits; doubling commits roughly doubles the work.
Time Complexity: O(n)
This means the time to squash commits grows linearly with the number of commits involved.
[X] Wrong: "Squashing many commits takes the same time as squashing just a few."
[OK] Correct: Each commit must be processed, so more commits mean more work and more time.
Understanding how git operations scale with input size shows you can think about tool efficiency and plan work better. This skill helps you explain your choices clearly in real projects.
What if we changed from squashing commits interactively to using a single merge commit? How would the time complexity change?