Why curl closes PRs on GitHub
daniel.haxx.se
Why curl closes PRs on GitHub
1–10 of 41 posts
Re: Why curl closes PRs on GitHub
#2> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually.
I thought maintainers can edit pull request? Why is that not used here?
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.
Re: Why curl closes PRs on GitHub
#3> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually. I thought maintainers can edit pull request? Why is that not used here? 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 contr…
> I thought maintainers can edit pull request? Why is that not used here?
The article says:
> That is however a clunky, annoying and time-consuming extra-step that not only requires that we (always) push code to other people’s branches, it also triggers a whole new round of CI jobs. This, only to get a purple blob instead of a red one. Not worth it.
> Not pulling someones PR also means he does not get any public attribution to it
I don't believe this is the case. Edited commits can keep the author (Author:, Co-Authored-By:).
> I'd say, don't use GitHub then
I'd say this would be throwing the baby with the bathwater.
(I'd also say amen to that though.)
> the maintainers are just too stubborn to implement them.
A gross mischaracterization of Daniel, from what I see. I was lucky to attend to his presentation at FOSDEM in February, he really seems to be a nice guy.
Re: Why curl closes PRs on GitHub
#4> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually. I thought maintainers can edit pull request? Why is that not used here? 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 contr…
> Not pulling someones PR also means he does not get any public attribution to it. He doesn't show up as a contributor, too
Manually merging a commit with fixups does not remove any attribution, what are you talking about? Who determines "committers to this project" by looking at the list of PRs on Github instead of the contributor list in the repo, the commits in the repo, ...?
Re: Why curl closes PRs on GitHub
#5> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually. I thought maintainers can edit pull request? Why is that not used here? 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 contr…
Commit messages are a Git feature. PR descriptions are a Github innovation and do not exist in repositories. curl's development is git-centric and not Github-centric.
Re: Why curl closes PRs on GitHub
#6> In order to make sure the commit message are correct, and in fact that the entire commit looks correct, we merge pull requests manually. I thought maintainers can edit pull request? Why is that not used here? 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 contr…
> Not pulling someones PR also means he does not get any public attribution to it. He doesn't show up as a contributor, too Manually merging a commit with fixups does not remove any attribution, what are you talking about? Who determines "committers to this project" by looking at the list of PRs on Github instead of the contributor list in the repo, the commits in the repo, ...?
I suspect the concern is less about who's credited in the curl repository on Github, and more about who gets to point to evidence on Github of having contributed to curl.
Re: Why curl closes PRs on GitHub
#7[deleted]
Re: Why curl closes PRs on GitHub
#8I 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?
Re: Why curl closes PRs on GitHub
#9I 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?
Squashing (by default) loses any individual commit information by squeezing out anything outside of the summary of each component commit. Editing from that state is usually far more work in the web UI than in a local editor.
Re: Why curl closes PRs on GitHub
#10Interesting. I made some contributions to the Zephyr RTOS project early this year, and they had a different approach to the same problems.
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.
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.