[arunix]

I remember in a previous job having to enable git rerere, otherwise it wouldn't remember previously resolved conflicts.

https://git-scm.com/book/en/v2/Git-Tools-Rerere

[nasretdinov]

I believe rerere is a local cache, so you'd still have to resolve the conflicts again on another machine. The recursive merge doesn't have this issue — the conflict resolution inside the merge commits is effectively remembered (although due to how Git operates it actually never even considers it a conflict to be remembered — just a snapshot of the closest state to the merged branches)

[Guvante]

Are people repeatedly handling merge conflicts on multiple machines?

If there was a better way to handle "I needed to merge in the middle of my PR work" without introducing reverse merged permanently in the history I wouldn't mind merge commits.

But tools will sometimes skip over others work if you `git pull` a change into your local repo due to getting confused which leg of the merge to follow.

[direwolf20]

The recursive merge is about merging branches that already have merges in them, while rerere is about repeating the same merge several times.

[pyrolistical]

Would be nice if centralized git platforms shared rerere caches

[lmm]

Rerere is dangerous and counterproductive - it tries to give rebase the same functionality that merge has, but since rebase is fundamentally wrong it only stacks the wrongness.

[seba_dos1]

Cherry-picks being "fundamentally wrong" is certainly an interesting git take.