What
I come to realize recently that most of the explanations about commits are in the commit title and PR description. while PR can be cloned and backup on alternative platform, I believe the git repository should be sufficient to have all the information needed about the intent of a commit. Some IDE do integrate commit <-> PR relation but that require privacy invasive calls to Github.
I made a comment on #618 because NO_COLOR was added as an environment variable but not listed in the PR description nor is it described in the commit message.
Most of our big PRs are actually squashed branch with concat titles from all the smaller commits.
Take a look at:
467a168
c597605
Where
I'm proposing that merged commits (obviously squashed so we just talk about a single commit) have this format:
TITLE
<General description that we often write in the PR description>
<Short reasoning and why>
<Changelog as compact as possible>
Optional: <List of squashed commits titles if found relevant>
Yes that make commit messages much longer but that is not idiosyncratic behavior when you consider that this is standard in mailing list based development (notably LKML comes to my mind).
What
I come to realize recently that most of the explanations about commits are in the commit title and PR description. while PR can be cloned and backup on alternative platform, I believe the git repository should be sufficient to have all the information needed about the intent of a commit. Some IDE do integrate commit <-> PR relation but that require privacy invasive calls to Github.
I made a comment on #618 because NO_COLOR was added as an environment variable but not listed in the PR description nor is it described in the commit message.
Most of our big PRs are actually squashed branch with concat titles from all the smaller commits.
Take a look at:
467a168
c597605
Where
I'm proposing that merged commits (obviously squashed so we just talk about a single commit) have this format:
Yes that make commit messages much longer but that is not idiosyncratic behavior when you consider that this is standard in mailing list based development (notably LKML comes to my mind).