Rerere for repeated conflict resolution in Git - Step-by-Step Execution

Process Flow - Rerere for repeated conflict resolution

Enable rerere

↓

Conflict occurs during merge

↓

Manually resolve conflict

↓

Commit resolved merge

↓

rerere records resolution

↓

Next time same conflict occurs

↓

rerere auto-applies recorded resolution

↓

User reviews and commits

↓

Conflict resolved faster

This flow shows how git rerere records your manual conflict resolutions and reuses them automatically when the same conflict happens again.

Execution Sample

Git

git config --global rerere.enabled true
git merge feature-branch
# resolve conflicts manually
git add .
git commit
# next merge with same conflict
git merge feature-branch

Enable rerere, merge causing conflict, resolve manually and commit, then next merge rerere auto-applies resolution.

Process Table

Step	Action	Conflict Detected?	rerere Behavior	User Action	Result
1	Enable rerere with config	No	rerere ready to record	None	rerere enabled
2	Merge feature-branch first time	Yes	No prior record	Manually resolve conflict	Conflict resolved manually
3	Commit merge	No	rerere records resolution	Commit changes	Resolution saved
4	Merge feature-branch second time	Yes	rerere detects same conflict	Review auto-applied resolution	Conflict auto-resolved
5	Commit merge	No	rerere reused resolution	Commit changes	Merge completed faster
6	Merge different branch	No	No rerere action	Normal merge	Merge completed normally

💡 No more merges or conflicts to resolve

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
rerere.enabled	false	true	true	true	true	true
conflict_state	none	detected	resolved	detected	resolved	none
rerere.record	empty	empty	saved	saved	saved	saved

Key Moments - 3 Insights

Why does rerere not auto-resolve the conflict the first time it happens?

Because rerere needs you to manually resolve the conflict once to record the resolution (see execution_table step 2 and 3). Only after that can it reuse the resolution.

What happens if the conflict is different from any previously recorded one?

rerere will not auto-apply any resolution and you must resolve manually again (see execution_table step 6).

Does rerere automatically commit the resolution for you?

No, rerere only applies the resolution. You still need to review and commit manually (see execution_table steps 4 and 5).

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What does rerere do when the same conflict occurs again?

A It automatically applies the previously recorded resolution

B It ignores the conflict and stops the merge

C It deletes the conflicting files

D It asks the user to resolve manually again

💡 Hint

Check the 'rerere Behavior' column at step 4 in the execution_table

According to variable_tracker, what is the state of 'rerere.record' after step 3?

A empty

B deleted

C saved

D unknown

💡 Hint

Look at the 'rerere.record' row and the 'After Step 3' column in variable_tracker

If rerere was not enabled at the start, what would happen at step 2?

A rerere would still record the resolution

B rerere would not record the resolution

C rerere would auto-apply resolution immediately

D rerere would cause merge to fail

💡 Hint

Refer to the 'rerere.enabled' variable in variable_tracker and step 1 in execution_table

Concept Snapshot

git rerere helps you reuse conflict resolutions.
Enable it with 'git config --global rerere.enabled true'.
When a conflict happens, resolve manually once and commit.
rerere records your fix.
Next time the same conflict occurs, rerere auto-applies your fix.
You still review and commit manually.

Full Transcript

This visual execution shows how git rerere works step-by-step. First, you enable rerere with a config command. When you merge a branch and get a conflict for the first time, you resolve it manually and commit. rerere records this resolution. Later, if the same conflict happens again during another merge, rerere automatically applies the recorded fix. You then review and commit the merge faster. If a different conflict occurs, rerere does not help and you resolve manually again. The variable tracker shows rerere.enabled turns true at start, conflict_state changes from none to detected and resolved, and rerere.record is saved after the first resolution. Key moments clarify that rerere only works after you manually resolve once, does not auto-commit, and ignores new conflicts. The quiz tests understanding of rerere's behavior during repeated conflicts and variable states.

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