Rerere for repeated conflict resolution in Git - Time & Space Complexity
We want to understand how the time to resolve conflicts changes when using Git's rerere feature.
Specifically, how does rerere affect the work needed when the same conflict happens multiple times?
Analyze the time complexity of this Git rerere workflow snippet.
git config --global rerere.enabled true
# Make changes causing a conflict
git merge feature-branch
# Resolve conflict manually
git add conflicted-file
# Commit merge
# Later, if the same conflict appears again:
git merge another-branch
# rerere auto-applies previous resolution
This snippet enables rerere, shows a conflict resolution, and then reuses that resolution automatically if the same conflict appears again.
Look for repeated work done when resolving conflicts.
- Primary operation: Manual conflict resolution by editing files.
- How many times: Once per unique conflict without rerere; multiple times if conflict repeats.
- With rerere: Conflict resolution is recorded once and reused automatically on repeats.
Imagine the number of repeated conflicts grows.
| Number of Repeated Conflicts (n) | Manual Resolutions Needed |
|---|---|
| 1 | 1 |
| 10 | 10 without rerere, 1 with rerere |
| 100 | 100 without rerere, 1 with rerere |
Without rerere, work grows linearly with repeated conflicts. With rerere, work stays almost constant after first resolution.
Time Complexity: O(1) for repeated conflict resolutions with rerere enabled
This means once a conflict is resolved, repeating it takes about the same small effort, no matter how many times it happens.
[X] Wrong: "rerere makes all merges instant and cost-free."
[OK] Correct: rerere only helps with conflicts that are exactly the same; new or different conflicts still need manual work.
Understanding rerere's time complexity shows you how automation can reduce repeated manual work, a key skill in efficient DevOps workflows.
What if rerere was disabled? How would the time complexity for repeated conflict resolution change?