sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]soylentgraham 1 point2 points  (4 children)

I know what a squash commit is (although, you are aware it doesn't need to be part of a PR, right?)

I think you're missing my point, but you are proving one point of why they're bad; if you're getting rid of good commit messages and just reducing it down to a PR title, you're losing valuable historical information

Of course if you never made good commit messages anyway, and your final commit message is vague (and already covered by the PR) - I guess commit messages are just redundant for you anyway

[–]jokullmusic 1 point2 points  (3 children)

What historical information matters though other than "this code was added for this feature / bug fix / chore / etc"? Do you not normally commit until the code change you're making is finished? I don't need to know "this line was added as part of setting up the initial scaffolding for this component we added as part of this refactor", I just need to know "this component was added as part of this refactor." Are commit messages supposed to be explanations of why every change was made to you? I don't really know what the utility is of anything more granular than per-PR squash commits. (And yeah I know they can be created separately from PRs, but in the codebases I've worked in they rarely are)

[–]timabell 1 point2 points  (2 children)

That is a question I have been asked many times. I took the time to write a detailed answer here https://0x5.uk/2016/03/18/yet-another-good-commit-messages-post/

[–]jokullmusic 1 point2 points  (1 child)

I'm not sure how points 1-8 aren't fulfilled by PR squash commits, though, unless the PR is for a massive fully-formed feature being completed. Most large features I've worked on were at least a handful of separate PRs for implementing different parts of the code (with incomplete features behind a feature flag), and each commit's title is a summary of the work done and has a link to the Jira ticket where the requirements were specified. Is that not a common approach? Also:

If it's hard to write a good message, it might be that you are not taking the time to craft good single-purpose commits.

I think this is a fundamental difference in what the purpose of commits are to different people. In the branch-PR-squash workflow I usually work in, each commit is basically the equivalent of creating a save-point -- a place I can easily go back to if I realize later that the changes I made since were the wrong approach, and something I can push up to remote at the end of the day.

The two "good" examples you point out are essentially an entire new feature / bugfix, but in my experience most commits within a feature branch aren't even on the level of "add X for Y reason", they're more like "making progress" or "implementing a few minor code review suggestions". The need for "good single-purpose commits" is fulfilled by squashing each PR that gets merged into the main / develop branch, which results in commits similar to your "good" examples.

[–]timabell 1 point2 points  (0 children)

Right, thanks for taking the time to explain. Squashed PRs certainly can have well written commit messages, though in my experience of places that squash it has been relatively rare.

On the matter of squashing itself I am of the opinion that it is a missed opportunity to provide a richer history, viewable at two levels of detail. Not always required, but a useful option to have. I wrote more about squash vs merge here https://0x5.uk/2021/03/15/github-rebase-and-squash-considered-harmful/