[herrkanin]

If writing good commit messages isn't specifically defined as part of your job, why would you waste business hours writing commit messages that are beyond what is expected of you and frankly useless since nobody would ever read it anyway?

[ickyforce]

In my opinion PR/changeset description is exactly what should be in the commit description. In cases were we had 1 commit per PR (i.e. squashing before merging) just copying the PR description into merge commit worked really well - the goal for a PR description and a commit is essentially the same.

I wish github allowed to make the copying automatic and ensure that it happens (it doesn't, unfortunately).

If someone wants to learn the full history - the remarks during code review, perhaps all the WIP commits - they can read the PR/code review comments. I found it to be very rarely needed.

[sgerenser]

This is exactly how Microsoft Azure DevOps works when you enable the squash-on-merge behavior (which is how we used it while working at Microsoft). I thought this was completely logical and I'm surprised that GitHub can't be configured the same way.

All of our commit messages were nice, long and detailed, with a link back to the PR if you really wanted to go back and see the individual commits and/or discussion that occurred on that PR. I think I only looked at individual commits maybe once or twice since they were usually useless in isolation (woops, WIP, fix typo, etc.).

[arccy]

settings > allow squash merging > default commit message > pull request title and description

[ickyforce]

Oh, nice, thanks. I haven't been using github recently, it looks like this option was added ~1.5y ago.

[erik_seaberg]

Writing good commit messages is part of your job in the sense that no reviewer should be approving anything without them, knowing that you may or may not be available if it breaks next year at 3 AM.

[kaashif]

I put that kind of thing in the pull request, since that's where the review happens. Every commit links back to a pull request, and people actually do refer back to it. Writing good documentation there is part of the job.

No-one's going to ALSO write commit messages that no-one will see.

[wnoise]

The git history will last longer than the platform hosting the PR.

[erik_seaberg]

Not only is “git log” always up, I can also skim it without opening a hundred browser tabs.

[cozzyd]

pull requests don't live in the repository (as far as I can tell...) and require you to use whatever online interface creates them.

Not sure whey e.g. Github Pull request merges don't include the entire pull request description in the merge commit message.

[DarkNova6]

In my company we norm the titles of MRs, give it a ticket number and squash it all. If you can’t concisely describe what you did you need to split your MR.

Helps with reviewing as well as blaming.

[groestl]

I'd do it for CYA purposes in case smt goes wrong and my commit is involved.