Reordering commits in Git - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When we reorder commits in git, we want to know how the time needed changes as the number of commits grows.
We ask: How does the effort to reorder commits grow when we have more commits?
Analyze the time complexity of the following git commands used to reorder commits.
git rebase -i HEAD~5
# Opens editor to reorder last 5 commits
# User changes order and saves
# Git applies commits in new order
This snippet shows an interactive rebase to reorder the last 5 commits by rewriting history.
Look for repeated steps in the rebase process.
- Primary operation: Git applies each commit one by one in the new order.
- How many times: Once for each commit being reordered (n times).
As the number of commits to reorder grows, git applies more commits sequentially.
| Input Size (n) | Approx. Operations |
|---|---|
| 5 | 5 commit applications |
| 50 | 50 commit applications |
| 500 | 500 commit applications |
Pattern observation: The work grows directly with the number of commits to reorder.
Time Complexity: O(n)
This means the time to reorder commits grows linearly with how many commits you reorder.
[X] Wrong: "Reordering commits is instant no matter how many commits there are."
[OK] Correct: Each commit must be reapplied, so more commits mean more work and time.
Understanding how git operations scale helps you explain your workflow choices clearly and shows you know how tools behave with bigger projects.
"What if we reorder only a subset of commits instead of all recent ones? How would the time complexity change?"
Practice
git rebase -i when working with commits?Solution
Step 1: Understand the function of
This command opens an interactive editor allowing you to reorder, edit, or squash commits.git rebase -iStep 2: Compare with other options
Creating branches, merging, or deleting history are not the main purposes of this command.Final Answer:
To reorder, edit, or squash commits interactively -> Option BQuick Check:
Interactive rebase = reorder commits [OK]
- Confusing rebase with branch creation
- Thinking rebase deletes history
- Mixing rebase with merge commands
Solution
Step 1: Recall the syntax for interactive rebase
The correct syntax usesHEAD~Nto specify the last N commits, soHEAD~3means last 3 commits.Step 2: Check other options for syntax errors
HEAD^3andHEAD^^3are invalid for this purpose;HEAD~is incomplete.Final Answer:
git rebase -i HEAD~3 -> Option AQuick Check:
Use HEAD~N for last N commits [OK]
- Using caret (^) incorrectly for commit range
- Omitting the number after ~
- Confusing HEAD~ with HEAD^
pick a1b2c3 Commit A pick d4e5f6 Commit B pick 789abc Commit C
If you change it to:
pick d4e5f6 Commit B pick a1b2c3 Commit A pick 789abc Commit C
What will be the order of commits after the rebase?
Solution
Step 1: Understand the todo list order
The interactive rebase applies commits in the order listed. Changing the order changes commit history order.Step 2: Apply the new order
New order is Commit B, then Commit A, then Commit C.Final Answer:
Commit B, Commit A, Commit C -> Option AQuick Check:
Rebase applies commits in listed order [OK]
- Assuming original order stays after rebase
- Confusing commit hashes with order
- Ignoring the todo list sequence
git rebase -i HEAD~3 and changed the order of commits, but Git shows a conflict error. What is the best way to fix this?Solution
Step 1: Understand rebase conflict handling
When conflicts occur during rebase, you must manually fix them in files.Step 2: Continue rebase after resolving conflicts
After fixing conflicts, rungit rebase --continueto proceed.Final Answer:
Manually resolve conflicts, then run git rebase --continue -> Option DQuick Check:
Fix conflicts + git rebase --continue [OK]
- Ignoring conflicts and force pushing
- Aborting rebase without trying to fix
- Deleting .git folder which loses repo data
Solution
Step 1: Use interactive rebase on last 4 commits
Runninggit rebase -i HEAD~4opens the last 4 commits for editing order.Step 2: Move the oldest commit line to the bottom
In the editor, reorder lines so the oldest commit is last, preserving content.Final Answer:
Run git rebase -i HEAD~4, then move the first commit line to the bottom in the editor -> Option CQuick Check:
Interactive rebase + reorder lines = reorder commits [OK]
- Using reset which loses commit history
- Trying non-existent git merge --reorder command
- Using wrong commit range in rebase
