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

      …and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.

      You then rebase so you have a nice linear history with no weird merge commits hanging around.

      • GissaMittJobb@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up

        The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.

        Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.

      • cobra89@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.

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

          There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.

          Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch

          Rebase takes your commit(s) and sticks them on the end.

          Merge does something else I don’t understand as well, and makes a merge commit.

          Also there was an earthquake in NYC when I was writing this. We may have angered the gods.

          • cobra89@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!

          • Atemu@lemmy.ml
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            7 months ago

            You should IMO always do this when putting your work on a shared branch

            No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.

            Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
            If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.

            Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.

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

              I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.

              Do you?

              Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.

              • Atemu@lemmy.ml
                link
                fedilink
                arrow-up
                1
                ·
                7 months ago

                Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.