Rerere for repeated conflict resolution in Git - Time & Space Complexity

Time Complexity: Rerere for repeated conflict resolution

O(1)

Understanding Time 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?

Scenario Under Consideration

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.

Identify Repeating Operations

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.

How Execution Grows With Input

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.

Final Time Complexity

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.

Common Mistake

[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.

Interview Connect

Understanding rerere's time complexity shows you how automation can reduce repeated manual work, a key skill in efficient DevOps workflows.

Self-Check

What if rerere was disabled? How would the time complexity for repeated conflict resolution change?

Practice

1. What is the main purpose of git rerere in conflict resolution?

easy

A. It creates a backup of your repository before merging.

B. It remembers how you resolved conflicts before and reuses those resolutions.

C. It deletes conflicting files after a merge.

D. It automatically merges branches without any conflicts.

Solution

1. Step 1: Understand what rerere stands for

   Rerere means "reuse recorded resolution" and helps with repeated conflicts.

2. Step 2: Identify its function in Git

   It saves conflict resolutions and applies them automatically if the same conflict happens again.

3. Final Answer:

   It remembers how you resolved conflicts before and reuses those resolutions. -> Option B

4. Quick Check:

   Rerere = reuse recorded resolution [OK]

Hint: Rerere reuses your past conflict fixes automatically [OK]

Common Mistakes:

• Thinking rerere merges without conflicts
• Believing rerere deletes files
• Assuming rerere backs up the repo

2. Which command correctly enables rerere globally in Git?

easy

A. git config --global rerere.enabled true

B. git config --global rerere.enable true

C. git rerere enable --global

D. git config rerere.enabled true --global

Solution

1. Step 1: Recall the correct config syntax for rerere

   The correct key is "rerere.enabled" with a dot, not "rerere.enable".

2. Step 2: Confirm the global flag placement

   The global flag comes immediately after "config" and before the key-value pair.

3. Final Answer:

   git config --global rerere.enabled true -> Option A

4. Quick Check:

   Correct syntax uses rerere.enabled with --global [OK]

Hint: Use 'rerere.enabled' with --global to enable rerere [OK]

Common Mistakes:

• Using rerere.enable instead of rerere.enabled
• Placing --global after the key-value pair
• Using 'git rerere enable' command which doesn't exist

3. Given this sequence of commands, what will git status show after the second merge if rerere is enabled?

git config --global rerere.enabled true
git checkout feature
# merge master with conflicts
# resolve conflicts manually and commit

git checkout feature
# merge master again with same conflicts

medium

A. No conflicts, because rerere applied previous resolutions automatically.

B. Conflicts remain and must be resolved again manually.

C. Merge fails with an error about unresolved conflicts.

D. Git deletes the conflicting files automatically.

Solution

1. Step 1: Understand rerere behavior on repeated conflicts

   When rerere is enabled, it remembers how you fixed conflicts and applies those fixes automatically on the same conflict.

2. Step 2: Analyze the second merge scenario

   The second merge has the same conflicts, so rerere applies the previous resolution, avoiding manual conflict fixing.

3. Final Answer:

   No conflicts, because rerere applied previous resolutions automatically. -> Option A

4. Quick Check:

   Rerere auto-applies fixes on repeated conflicts [OK]

Hint: Rerere auto-fixes repeated conflicts after first manual fix [OK]

Common Mistakes:

• Expecting conflicts again despite rerere
• Thinking merge will fail with error
• Assuming files get deleted automatically

4. You enabled rerere but notice it does not apply previous conflict resolutions automatically. What is a likely cause?

medium

A. You enabled rerere only locally, not globally.

B. You used git rerere clear before the second merge.

C. You forgot to commit the conflict resolution the first time.

D. You merged branches with no conflicts.

Solution

1. Step 1: Understand how rerere records resolutions

   Rerere saves conflict resolutions only after you commit the resolved merge.

2. Step 2: Identify why rerere might not apply fixes

   If you did not commit the resolution, rerere has no record to reuse, so it cannot auto-apply fixes.

3. Final Answer:

   You forgot to commit the conflict resolution the first time. -> Option C

4. Quick Check:

   Rerere needs committed resolutions to reuse [OK]

Hint: Commit conflict fixes first for rerere to remember them [OK]

Common Mistakes:

• Assuming rerere works without committing resolutions
• Confusing rerere clearing with enabling
• Thinking local vs global enable affects this issue

5. You have a project where the same conflict happens often between two branches. How can you use rerere to save time and avoid repeated manual fixes? Choose the best approach.

hard

A. Run git rerere clear before every merge to reset conflict history.

B. Disable rerere and always resolve conflicts manually to avoid mistakes.

C. Use rerere only on one branch and manually copy resolutions to the other branch.

D. Enable rerere globally, resolve the conflict once and commit, then rerere will auto-apply fixes on future merges.

Solution

1. Step 1: Enable rerere globally for all repositories

   This ensures rerere is active and can record conflict resolutions anywhere.

2. Step 2: Resolve the conflict once and commit the fix

   Rerere records this resolution to reuse it automatically on repeated conflicts.

3. Step 3: Benefit from rerere auto-applying fixes on future merges

   This saves time by avoiding repeated manual conflict resolution.

4. Final Answer:

   Enable rerere globally, resolve the conflict once and commit, then rerere will auto-apply fixes on future merges. -> Option D

5. Quick Check:

   Enable + commit fix = rerere auto-applies [OK]

Hint: Enable rerere, commit fix once, future merges auto-fix [OK]

Common Mistakes:

• Disabling rerere loses automation benefits
• Using rerere only on one branch misses conflicts
• Clearing rerere history removes saved fixes