-
-
Notifications
You must be signed in to change notification settings - Fork 862
Improve "Commit Messages" section in committing.rst #199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sounds good. Some comments:
It's briefly mentioned in here, but I think makes more sense now to move this into Committing section.
I'm inclined to keep the [X.Y] in the commit message, only because cherry_picker.py is doing this by default. I also understand that not everyone uses it, and also cherry_picker.py is supposed to be temporary until a bot is in place. So I won't oppose omitting it from the commit message. |
I took a small poll here at the PyCon US sprints and basically everyone uniformly said "keep the branch label" and "don't care about the listed PRs", so basically just keep the title intact compared to what we have people specify for PRs currently. |
@berkerpeksag I think everything has been addressed, so I'm closing this. Please reopen if it turns out that I miss something. Thanks. |
It would be great if we could tweak the section at http://cpython-devguide.readthedocs.io/committing.html#commit-messages a bit. For example,
It doesn't include
(GH-NNNN)
suffix in the first line:It doesn't mention about stripping unnecessary parts when doing the merge (see python/cpython@6924ed5 for example)
It doesn't talk about what to do with backport PRs (e.g. should we drop the backport PR number from the title?)
Currently, we do have:
#4242 is the backport PR here, but it's rarely useful and it can be seen by using the GitHub UI.
I suggest stripping it and only keep the original PR number:
Another question is that should we add
[X.Y]
to commit messages too or should we only add it to the PR title?It doesn't talk about what to do with
GH-NNNN
annotations when the first line of the commit message is too long. See python/cpython@edef358 for example. Should we move the annotation to the end of the commit message in this case? For example:The text was updated successfully, but these errors were encountered: