[GH-ISSUE #542] Consider changing pull request practices with relevant GitHub features in mind #2292

New issue

Closed

opened 2026-03-07 20:06:23 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 20:06:23 +03:00

Owner

Originally created by @Piedone on GitHub (Jul 29, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/542

The contribution guidelines require two things that I find quite unique:

"Pull requests should contain a single commit."
"Include the text "(fixes #??)" at the end of the commit message so the pull request will be associated with the relevant issue."

It's your project and your rules which I respect, of course. Just you might not be aware, that both of these (as well as the period-enforcing rule for commit messages) can be achieved easily by utilizing the below GitHub features, and thus not requiring the contributor to do anything specific, hence potentially lowering the barrier of entry (especially that you don't have to get things right the first time this way):

You can squash all commits of a PR when doing the merge, thus you'll end up with a single commit on next, regardless of how many the contributor added in their fork. Allowing multiple commits under a PR also doesn't necessitate the contributor to continuously rewrite history when addressing PR feedback with new changes. Furthermore, the reviewer will be able to see changes since their last review easily (also using the GitHub feature for this).
When merging a PR, you can customize the commit message for the squash commit too.
You can make a PR attached to an issue, and thus the issue auto-close on PR merge by including the "Fixes #issue-id" text in its description.

Originally created by @Piedone on GitHub (Jul 29, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/542 [The contribution guidelines](https://github.com/DavidAnson/markdownlint/blob/main/CONTRIBUTING.md) require two things that I find quite unique: - "Pull requests should contain a single commit." - "Include the text "(fixes #??)" at the end of the commit message so the pull request will be associated with the relevant issue." It's your project and your rules which I respect, of course. Just you might not be aware, that both of these (as well as the period-enforcing rule for commit messages) can be achieved easily by utilizing the below GitHub features, and thus not requiring the contributor to do anything specific, hence potentially lowering the barrier of entry (especially that you don't have to get things right the first time this way): - [You can squash all commits of a PR when doing the merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-pull-request-commits), thus you'll end up with a single commit on `next`, regardless of how many the contributor added in their fork. Allowing multiple commits under a PR also doesn't necessitate the contributor to continuously rewrite history when addressing PR feedback with new changes. Furthermore, the reviewer will be able to see changes since their last review easily (also using the GitHub feature for this). - When merging a PR, you can customize the commit message for the squash commit too. - You can make a PR attached to an issue, and thus the issue auto-close on PR merge by including the "Fixes #issue-id" text in its description.

kerem

2026-03-07 20:06:23 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 20:06:24 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jul 29, 2022):

Thanks for the suggestions! Regarding having a single commit, that is how I would prefer it, though I regularly squash commits as you suggest. The same goes for the format of the commit message; I will update it if it doesn't look right. That said, I would rather not have to do these things as a maintainer; it's a distraction from reviewing the change itself. There are times it would be quicker for me to make a change myself then to fix up a proposed commit, etc.. I do it to encourage a healthy open-source ecosystem, but it's not ideal. Regarding including the issue number in the commit message, I find that most convenient when scanning "git log" output. I know there are PR gates that enforce things like this, but I've contributed to projects where I spent more time editing the commit message that I did making the code fix! This project's current trade-offs of asking but not requiring have worked reasonably well for me so far.

@DavidAnson commented on GitHub (Jul 29, 2022): Thanks for the suggestions! Regarding having a single commit, that is how I would prefer it, though I regularly squash commits as you suggest. The same goes for the format of the commit message; I will update it if it doesn't look right. That said, I would rather not have to do these things as a maintainer; it's a distraction from reviewing the change itself. There are times it would be quicker for me to make a change myself then to fix up a proposed commit, etc.. I do it to encourage a healthy open-source ecosystem, but it's not ideal. Regarding including the issue number in the commit message, I find that most convenient when scanning "git log" output. I know there are PR gates that enforce things like this, but I've contributed to projects where I spent more time editing the commit message that I did making the code fix! This project's current trade-offs of asking but not requiring have worked reasonably well for me so far.

kerem commented

2026-03-07 20:06:24 +03:00

Author

Owner

@Piedone commented on GitHub (Jul 31, 2022):

Understandable, thanks for explaining.

@Piedone commented on GitHub (Jul 31, 2022): Understandable, thanks for explaining.