• sushibowl@feddit.nl
    link
    fedilink
    arrow-up
    3
    ·
    2 months ago

    The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”

    You can improve the situation with git rerere

    • Cyborganism@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      Holy shit! I never took the time to read about it rerere. But it all makes sense now.

      However, it’s still a lot of extra steps for what could otherwise be really simple with a regular merge.

      Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It’s it really worth all the hassle? Especially if you’re using a squash merge in a pull request…

    • zalgotext@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      I don’t think rerere applies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.