Recovering from bad rebase in Git - Time & Space Complexity
When recovering from a bad rebase in git, we want to understand how the time to fix the problem grows as the number of commits involved increases.
We ask: How does the effort to undo or fix a rebase scale with the number of commits?
Analyze the time complexity of the following git commands used to recover from a bad rebase.
git reflog
# Find the commit before the bad rebase
git reset --hard <commit-hash>
# Reset branch to that commit
# Optionally, reapply changes carefully
This snippet shows how to find the safe commit and reset the branch to undo the bad rebase.
Look for repeated steps or operations that grow with input size.
- Primary operation: Scanning the reflog entries to find the correct commit.
- How many times: Number of reflog entries equals number of recent commits and actions.
The time to find the right commit grows as the number of commits in reflog grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 commits | Scan about 10 reflog entries |
| 100 commits | Scan about 100 reflog entries |
| 1000 commits | Scan about 1000 reflog entries |
Pattern observation: The effort grows linearly with the number of commits you check.
Time Complexity: O(n)
This means the time to recover grows in direct proportion to the number of commits you need to review.
[X] Wrong: "Resetting after a bad rebase is instant no matter how many commits there are."
[OK] Correct: You must find the correct commit in the reflog, which takes longer if there are many commits to check.
Understanding how recovery steps scale helps you explain your troubleshooting approach clearly and shows you grasp practical git workflows.
"What if you used git reflog with a filter or limit? How would that affect the time complexity of finding the right commit?"