Interesting. I made some contributions to the Zephyr RTOS project early this year, and they had a different approach to the same problems.<p>It seems like Curl makes it the maintainers' job to do the rebasing and commit-style corrections. Zephyr, on the other hand, put it on the pull request's creator. I ended up force-pushing and rebasing half a dozen times because I had to learn all their rules the hard way.<p>I don't think either method is necessarily better than the other - it depends on the project. Zephyr's approach lets the maintainers focus on more important things than commit-style yak shaving, while curl's approach lowers the barrier to entry for inexperienced contributors.
I was working at a company that hired a lot of people new to dev. So one guy, comes to us saying his commits arent matching the standard they want. I see his commits, and I see like 50 of them that just say stuff like "fixing the bug", "finally fixing the bug", I tried to tell him, try to describe what the code is changing / doing with this commit as if you had to explain it to you mom. He gave me a look like I was crazy and proceeded to ask someone else for help. I assume he's still committing with awful messaging that matches their desired format.
I think the big take away is that GitHub should add a "Merges #X" feature similar to Closes #X as Daniel suggests.<p>An additional problem with closing a pull request instead of "purple merging" it is that it gives off the wrong end result when you view the pull request from the pull requests view, as an activity comment in a related issue, or by viewing the top of a pull request. Red should mean change rejected and purple should mean change accepted, regardless of the mechanism by which the code was accepted.
Is the issue just that the commit messages aren't considered important in Github's UI? There's a few tools that do this better, notable Reviewable.io makes the commit message(s) into a virtual file that can be commented on.<p>Disclosure: I used to work at Reviewable
From time to time I merge PR in Racket, and they need a rebase or a tiny tweak. In those case I post a closing comment like<p>> <i>Thanks! Merged in 67b421.</i><p>So the author can find the final version merge in the main branch.
I set up GitHub to squash and merge commits by default, and to use the pull
request title and description as the commit message instead of the individual
commit messages. Won't that be helpful here?
I'm glad to see someone else annoyed that GitHub doesn't allow commenting on the commit messages directly. One of the things I miss from Gerrit.
For people who prefer rebase and force push, <a href="https://getcord.github.io/spr/" rel="nofollow">https://getcord.github.io/spr/</a> is a great tool resembling Phabricator's `arc diff`.<p><a href="https://github.com/orgs/community/discussions/3478">https://github.com/orgs/community/discussions/3478</a> ("Improve workflow when force-pushing during code reviews") could use more support.<p>I've also got lots of complaints in this section when LLVM switched to GitHub PR: <a href="https://maskray.me/blog/2023-09-09-reflections-on-llvm-switch-to-github-pull-requests#patch-evolution" rel="nofollow">https://maskray.me/blog/2023-09-09-reflections-on-llvm-switc...</a>
Couldn't they just edit the PR branch directly? When I make PRs I have an option "Allow edits by maintainers" which I assume would give them write access to my branch?<p>Edit: "We COULD but we won’t" actually addresses that, but it just wasn't obvious to me that they were referring to that feature. I can't delete this comment anymore.
> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually.<p>I thought maintainers can edit pull request? Why is that not used here?<p>The also say they don't want GitHub dictating them how to use git. I'd say, don't use GitHub then. Not pulling someones PR also means he does not get any public attribution to it. He doesn't show up as a contributor, too. I find that problematic and would say, there are simple ways around all the issues that have been listed, but the maintainers are just too stubborn to implement them.