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

    I consider myself above average in terms of Git know how. But I’ve come across situations using rebase where you’re stuck resolving the same conflicts over several commits.

    I still don’t understand that part quite well.

    This doesn’t happen when you do a normal merge though. Making it easier to manage

    • CMahaff@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 months ago

      Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.

      Works great if you’re willing to lose the commit history on your branch, which obviously isn’t always the case.

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

        Yeah that’s what I did as a workaround. Reset (soft) to the first parent commit and do a single commit with all the changes.

    • 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.

    • jjjalljs@ttrpg.network
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      I usually squash my local into a single commit, then rebase it onto the head of main. Tends to be simpler

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

      That could happen if the base branch has changed a lot since the last time you rebased against it. Git may make you resolve new conflicts that look similar to the last time you resolved them, but they are in fact new conflicts, as far as git can tell.

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

        All it can take is one commit in the parent branch. If your branch has many commits because you’re a commit freak then your fucked.

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

          Only if there are changes in the same files and on the same lines in both branches. And if you’re a commit freak, you should probably be squashing/amending, especially if you’re making multiple commits of changes on the same lines in the same files. The --amend flag exists for a reason. No one needs to see your “fixed things”, “changed things again”, “fixed it for real” type commits.

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

            What I do locally on my branch is my own business.

            Honestly, when doing a merge/pull request into the parent branch, that’s when you squash. You don’t need the entire history of a development branch in main.

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

              What I do locally on my branch is my own business.

              Lol ok, but don’t expect git to read your mind. Like I said earlier, if people take a day or two to understand the tool, they can adjust their personal workflows to work better within the confines of git.

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

                I agree.

                Unfortunately, from experience, nobody seems to have time for that. They just learn git pull, push, add, commit and merge and that’s about it.

                Sometimes they’ll use checkout and end up in detached head and have a panic attack. That’s when I come in. lol