4 ms·

> Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes Of course not, that would be sil

> Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes Of course not, that would be silly, but who is doing that? I suppose some silly outfits have long lived branches onto which they throw lots of stuff then finally go back to master, but that isn't what this article is arguing about. If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself. Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have. As someone else said, it is such an engineering nitpick "you're using it wrong" type of article. We enforce squash commits when we mere PRs to master, and we never have any issues with it.

lucasoshiro 2y ago
> If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself. Read the rewriting tools references in the text. > Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have. Read again about the debugging tools mentioned. I never saw a code that needed some kind of debugging. Keeping the history clean makes the debug easier. You could also say the same about tests. Tests don't solve any problem as long as the code works. But if it doesn't work, test will help to quickly find out where it is broken. Otherwise, you have no benefit of squashing. If you don't see the benefits of having a commit history, you can use Google Drive instead. > We enforce squash commits when we mere PRs to master, and we never have any issues with it. 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...

lucasoshiro 2y ago

> If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself. Read the rewriting tools references in the text. > Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have. Read again about the debugging tools mentioned. I never saw a code that needed some kind of debugging. Keeping the history clean makes the debug easier. You could also say the same about tests. Tests don't solve any problem as long as the code works. But if it doesn't work, test will help to quickly find out where it is broken. Otherwise, you have no benefit of squashing. If you don't see the benefits of having a commit history, you can use Google Drive instead. > We enforce squash commits when we mere PRs to master, and we never have any issues with it. 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...