5 ms·

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-Tool

by arunix 8mo ago

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 https://git-scm.com/book/en/v2/Git-Tools-Rerere

nasretdinov 8mo ago
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 8mo ago
  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.
  - nasretdinov 8mo ago
    One place where it mattered was when I was working on a large PHP web site, where backend devs and frontend devs would be working in the same branch — this way you don't have to go back and forth to get the new API, and this workflow was quite unique and, in my mind, quite efficient. The branchs also could live for some time (e.g. in case of large refactorings), and it's a good idea to merge in the master branch frequently, so recursive merge was really nice. Nowadays, of course, you design the API for your frontend, mobile, etc, upfront, so there's little reason to do that anymore.
    - Guvante 8mo ago
      Honestly if the tooling were better at keeping upstream on the left I wouldn't mind as much but IIRC `git pull` puts your branch on the left which means walking history requires analysing each merge commit to figure out where history actually is vs where a temporary branch is. That is my main problem with merge, I think the commit ballooning is annoying too but that is easier to ignore.
direwolf20 8mo ago
The recursive merge is about merging branches that already have merges in them, while rerere is about repeating the same merge several times.
pyrolistical 8mo ago
Would be nice if centralized git platforms shared rerere caches
lmm 8mo ago
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 8mo ago
  Cherry-picks being "fundamentally wrong" is certainly an interesting git take.

by arunix 8mo ago

nasretdinov 8mo ago

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 8mo ago
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.
- nasretdinov 8mo ago
  One place where it mattered was when I was working on a large PHP web site, where backend devs and frontend devs would be working in the same branch — this way you don't have to go back and forth to get the new API, and this workflow was quite unique and, in my mind, quite efficient. The branchs also could live for some time (e.g. in case of large refactorings), and it's a good idea to merge in the master branch frequently, so recursive merge was really nice. Nowadays, of course, you design the API for your frontend, mobile, etc, upfront, so there's little reason to do that anymore.
  - Guvante 8mo ago
    Honestly if the tooling were better at keeping upstream on the left I wouldn't mind as much but IIRC `git pull` puts your branch on the left which means walking history requires analysing each merge commit to figure out where history actually is vs where a temporary branch is. That is my main problem with merge, I think the commit ballooning is annoying too but that is easier to ignore.

direwolf20 8mo ago

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

pyrolistical 8mo ago

Would be nice if centralized git platforms shared rerere caches

lmm 8mo ago

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 8mo ago
Cherry-picks being "fundamentally wrong" is certainly an interesting git take.