3 ms·

The author's reasoning behind not squashing: https://blog.ploeh.dk/2020/10/05/fortunately-i-dont-squash-my-commits https://blog.ploeh.dk/2020/10/05/fortunately-

The author's reasoning behind not squashing: https://blog.ploeh.dk/2020/10/05/fortunately-i-dont-squash-my-commits https://blog.ploeh.dk/2020/10/05/fortunately-i-dont-squash-m... I can understand they don't want to oversquash - I rebase & squash so that each commit should be able to stand on its own. I think the above link is a good argument for squashing (and rebasing) to the point that each commit should leave the system in a state where everything works, because otherwise you can't use `git bisect` and actually determine if it's good or bad. I will often have more granular commits where I break something and then fix it in the next commit.

justsomehnguy 5y ago
> rebase & squash so that each commit should be able to stand on its own. IMO this is classical example of "don't solve the administrative tasks with technical means". Git is a tool, how do you use it is up to you.
obelos 5y ago
Yeah, I think you're asking for trouble if you start squashing commits on code that has been deployed, which is the situation he seems to be describing here. I can't see any net benefit to that, and can see a whole lot of trouble. Any time your code has been shared outside your personal development environment, rebasing is dicey. The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials.
- account42 5y ago
  > The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials. Even then, you can't unleak auth credentials so you will need to change them anyway. Then leaving the commit, while embarrasing, is no longer an actual issue.
jaitsu 5y ago
Given most teams operate CI pipelines on their PRs/MRs, I like to make it a requirement to squash before merging. This means that only passing builds make it into the main branch. The value of this cannot be underestimated, in my experience, as using things like “git bisect” mean you always have a working build.

justsomehnguy 5y ago

> rebase & squash so that each commit should be able to stand on its own. IMO this is classical example of "don't solve the administrative tasks with technical means". Git is a tool, how do you use it is up to you.

obelos 5y ago

Yeah, I think you're asking for trouble if you start squashing commits on code that has been deployed, which is the situation he seems to be describing here. I can't see any net benefit to that, and can see a whole lot of trouble. Any time your code has been shared outside your personal development environment, rebasing is dicey. The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials.

account42 5y ago
> The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials. Even then, you can't unleak auth credentials so you will need to change them anyway. Then leaving the commit, while embarrasing, is no longer an actual issue.

jaitsu 5y ago

Given most teams operate CI pipelines on their PRs/MRs, I like to make it a requirement to squash before merging. This means that only passing builds make it into the main branch. The value of this cannot be underestimated, in my experience, as using things like “git bisect” mean you always have a working build.