3 ms·
Interactive rebasing away fixups in your branch is not squash merging. I agree that fixing a typo in a variable or a small linting issue in a previous (recent o
by MartijnHols 2y ago
Interactive rebasing away fixups in your branch is not squash merging. I agree that fixing a typo in a variable or a small linting issue in a previous (recent or not-pushed) commit in your branch is usually good. A carefully crafted commit history is all anyone can ask for. But then squashing away that history once the PR is merged would be a waste of a good history and the effort you put into it. If you end up squashing your history away anyway, why bother cleaning it up in an interactive rebase?
- munksbeer 2y agoI can't follow what you're saying. Once people start reviewing the PR, we typically do not manually squash (rebase -i) because it is helpful to see how the flow of the review went. Following this, we sometimes end up with 10 commits on a PR that are just addressing various comments, nitpicky or not. Then once approved, we click the "squash and merge" button, and github squashes all that useless noise into a single commit on master for us. We don't have any complaints about this workflow.
- lucasoshiro 2y ago> Then once approved, we click the "squash and merge" button, and github squashes all that useless noise into a single commit on master for us. This is not what squash is. I suggest you to read again the section "What squash merge actually is". tl;dr: "Squash merge is the same as the true merge but with a missing information: the reference to the merged branch." > We don't have any complaints about this workflow. Repeating the same answer: Just because you never had doesn't mean that they don't exist. If you saw it at least once, it means that it exists. I saw it once, and I related here: https://lucasoshiro.github.io/posts-en/2024-06-27-squash-submodule/ https://lucasoshiro.github.io/posts-en/2024-06-27-squash-sub...