4 ms·

Why no squash? It's a private dev branch, so it doesn't throw off anyone else's work. Just commit to your heart's content for every little experiment. Write tri

by obelos 5y ago

Why no squash? It's a private dev branch, so it doesn't throw off anyone else's work. Just commit to your heart's content for every little experiment. Write trivial commit messages like “checkpoint” because `git show` will contain so little code it's easy to figure out what's what. If you later decide you've headed down the wrong path, `git checkout -b my_feature_take2 HEAD~n` and start back up from a known point. When you have a functional final result, `git rebase -i master` to squash and groom the commits into more meaningful aggregations. Or just a single commit, if it makes sense for the context. Interactive rebasing with fixup/squash makes the end result very readable. `git reset` and `git add -p` can also be a huge boon when tidying up a branch before PR.

bentcorner 5y ago
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.

by obelos 5y ago

bentcorner 5y ago

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.