• zalgotext@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    3 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
      0
      ·
      3 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
        0
        ·
        3 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
          0
          ·
          3 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
            0
            ·
            3 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.