4 ms·

Another benefit of not squashing is it encourages devs to think about their commits and is a great opportunity to document what you are doing when they are doin

Another benefit of not squashing is it encourages devs to think about their commits and is a great opportunity to document what you are doing when they are doing it. If you are squashing 10 commits with junk commit messages (because devs know there is little value in having meaningful commits in what will be a squashed branch), trying to summarize all the changes into a meaningful commit message is hard. It can be valuable to see the intention of atomic commits in git history. The squash branch on merge strategy is just lazy and is counterproductive to having meaningful git history.

jaredsohn 2y ago
I prefer to add commentary in the PR on the final changes - what does it do, how does it work, what are some pieces of code I'm less sure of, etc. It is accessible since the squashed commit gets linked to it and that provides a place for people to ask questions. Also is a lot faster to write and easier to communicate compared to messing around with moving code across commits, ensuring tests pass across them, etc. Basically I think people care more about what was built and how it works rather than how to split it up step by step (although if the latter is important I can add a comment for that on the PR - although ideally it would have been separate PRs.)
- 000ooo000 2y ago
  >I prefer to add commentary in the PR on the final changes That vanishes when you shift forges
sjburt 2y ago
I think the problem is that often the order you want it in a clean history is not exactly the chronological order it was developed. Eg you may build out a feature vertically, tweaking the interfaces between the components as you go along. But a clean, atomic git history would probably introduce each component in a finished state in separate commits.
recursive 2y ago
This depends on the assumption that going to the trouble of making a carefully curated commit history well documented is even worth the trouble. Sometimes it might be, but I don't think it's a given. > The squash branch on merge strategy is just lazy "Lazy" is the negative way of saying "easy" or even "more efficient". "Lazy" implies that the other way is better. Is it? Maybe sometimes. Am I "lazy" if I walk on my feet instead of my hands? It really is a lot easier.

jaredsohn 2y ago

I prefer to add commentary in the PR on the final changes - what does it do, how does it work, what are some pieces of code I'm less sure of, etc. It is accessible since the squashed commit gets linked to it and that provides a place for people to ask questions. Also is a lot faster to write and easier to communicate compared to messing around with moving code across commits, ensuring tests pass across them, etc. Basically I think people care more about what was built and how it works rather than how to split it up step by step (although if the latter is important I can add a comment for that on the PR - although ideally it would have been separate PRs.)

000ooo000 2y ago
>I prefer to add commentary in the PR on the final changes That vanishes when you shift forges

sjburt 2y ago

I think the problem is that often the order you want it in a clean history is not exactly the chronological order it was developed. Eg you may build out a feature vertically, tweaking the interfaces between the components as you go along. But a clean, atomic git history would probably introduce each component in a finished state in separate commits.

recursive 2y ago

This depends on the assumption that going to the trouble of making a carefully curated commit history well documented is even worth the trouble. Sometimes it might be, but I don't think it's a given. > The squash branch on merge strategy is just lazy "Lazy" is the negative way of saying "easy" or even "more efficient". "Lazy" implies that the other way is better. Is it? Maybe sometimes. Am I "lazy" if I walk on my feet instead of my hands? It really is a lot easier.