Everything starts with the commits. Their text is your first line of
defense. Think of this as what will appear in the logs.
Interestingly, commit messages have seemed to shrink ever since people
started using pull requests. GitHub focuses attention on the pull
request description and subsequent comments, and de-emphasizes the
commit messages which it displays in a smaller font. By default GitHub
pull requests hide multi-line commit messages until you click a plus
button to expand them. The net effect is that people consider the PR as
the artifact of interest and the commit as a trifling accessory.
Perhaps this was an intentional design choice, because it means if you
ever want to migrate to another git hosting service then you would lose
the bulk of the communication metadata (that they guided you to store
outside the repo itself).
Compare your typical commit messages to those in the Postgres project
(where they don’t use pull requests):
To be fair, both of your examples are “real” projects, instead of, say, web stuff or Javascript frameworks or something.
My commit messages back when I was working on low-level C libraries and things were leagues better than what I do today, since there tended to be a lot less of change margin to align with newsletter-type issues. Different engineering cultures.
Interestingly, commit messages have seemed to shrink ever since people started using pull requests. GitHub focuses attention on the pull request description and subsequent comments, and de-emphasizes the commit messages which it displays in a smaller font. By default GitHub pull requests hide multi-line commit messages until you click a plus button to expand them. The net effect is that people consider the PR as the artifact of interest and the commit as a trifling accessory.
Perhaps this was an intentional design choice, because it means if you ever want to migrate to another git hosting service then you would lose the bulk of the communication metadata (that they guided you to store outside the repo itself).
Compare your typical commit messages to those in the Postgres project (where they don’t use pull requests):
https://git.postgresql.org/gitweb/?p=postgresql.git;a=log
…or in Linux, which also stays away from GitHub:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?showmsg=1
To be fair, both of your examples are “real” projects, instead of, say, web stuff or Javascript frameworks or something.
My commit messages back when I was working on low-level C libraries and things were leagues better than what I do today, since there tended to be a lot less of
change margin to align with newsletter-type issues. Different engineering cultures.