Re: [PATCH 4/4] merge-recursive: Avoid showing conflicts with merge branch before HEAD

Elijah Newren writes: > The correct order usually comes naturally and for free, but with renames > we often have data in the form {rename_branch, other_branch}, and > working relative to the rename first (e.g. for rename/add) is more > convenient elsewhere in the code. Address the slight impedan

[PATCH 4/4] merge-recursive: Avoid showing conflicts with merge branch before HEAD

We want to load unmerged entries from HEAD into the index at stage 2 and from MERGE_HEAD into stage 3. Similarly, folks expect merge conflicts to look like HEAD content from our side content from their side MERGE_HEAD not MERGE_HEAD content from their side ==