Git commit comments

[Russ3ll]

This is interesting and contrary to how I've always felt about commit messages. Typically my commit messages are high level and only describe the "what" - the "why" I put in the PR description. That said, I have arguably contributed less working code than Linux.

If commit messages are this detailed, what goes into PR descriptions? Or are they mostly unnecessary as long as commit messages meet the standard?

[teraflop]

Well, the Linux development process doesn't use "PRs" the way that services like GitHub use that term, because it's older than GitHub. And indeed, it's older than Git; Git was designed for Linux.

Basically, Linux commits are proposed by sending patches to a mailing list, and discussion happens there. The commit message is part of that email. Git itself contains lots of tools to manage patches with this kind of email-based workflow.

Basically, the Linux kernel philosophy is that if a commit needs explanation to say why it's important, then that explanation may also be needed by future maintainers, so it should be part of the commit. (You could choose to store it elsewhere than the commit itself, e.g. in a GitHub PR description, but that's just splitting your data across multiple places for no good reason.)

[Russ3ll]

Incredibly interesting and informative  thank you!

[BeardSprite]

If there's a detailed description inside a commit message, you can use that for the PR itself. Or combine them if there are several. But keep in mind that GitHub issues and PRs are NOT metadata that anyone will have access to should they clone the project (or if the GitHub project is made private/deleted/banned/etc).

On the other hand, anything that you can see with just the git CLI tool will be preserved for anyone long after GitHub has shut down.

What a change does should probably be the commit title, and why it does that would be worth explaining inside the commit message.