4 ms·

> 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 maintainer

by 7bit 2y ago

> 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.

jraph 2y ago
> 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.
detaro 2y ago
> 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, ...?
- throwanem 2y ago
  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.
  - detaro 2y ago
    ... then point to your commits in the curl repo on Github?
    - throwanem 2y ago
      I'm not expressing a preference here; this isn't a problem I have. But I do also suspect that a project with as high a profile as curl sees a lot of trivial PRs with less intent to improve the software, than to have the merge show up on the contributor's behalf in Github's various recruiter-friendly metrics. How that intent plays with Git as Git is done, versus how Github does it, I have no idea. But the existence of the article, and the perspective toward which it seems to be written, suggest to me the answer is "not well" and that Stenberg et al may be seeing the same questions and complaints frequently recurring about this.
      - detaro 2y ago
        But that's my point, what are these metrics that supposedly don't show the contributions anymore? Because the (IMHO) important ones all still show it, because they go by commit authorship in the repo, so you still get listed in the important places and can point to them.
        throwanem 2y ago
        Well, fair enough: as I said, I don't know. The commenter with whom you originally raised the question can probably answer better there.
throwanem 2y ago
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.
mathstuf 2y ago
> I thought maintainers can edit pull request? Why is that not used here? I don't know if Github has it, but GitLab supports "push options"[1] where you can say "skip CI". There are other mechanisms, but they stay in the history since they live in the commit message (and the summary of all places!). Github seems allergic to any features that are mostly useful to "rewrite history" workflows though, so I wouldn't be surprised if that wasn't around. > Not pulling someones PR also means he does not get any public attribution to it. We use self-hosted GitLab and mirror on Github; I get boxes filled in on my Github account's grid and properly attributed in Github's stats despite only ever showing up there via `git push` commands. [1]https://docs.gitlab.com/ee/user/project/push_options.html https://docs.gitlab.com/ee/user/project/push_options.html

by 7bit 2y ago

jraph 2y ago

> 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.

detaro 2y ago

> 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, ...?

throwanem 2y ago
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.
- detaro 2y ago
  ... then point to your commits in the curl repo on Github?
  - throwanem 2y ago
    I'm not expressing a preference here; this isn't a problem I have. But I do also suspect that a project with as high a profile as curl sees a lot of trivial PRs with less intent to improve the software, than to have the merge show up on the contributor's behalf in Github's various recruiter-friendly metrics. How that intent plays with Git as Git is done, versus how Github does it, I have no idea. But the existence of the article, and the perspective toward which it seems to be written, suggest to me the answer is "not well" and that Stenberg et al may be seeing the same questions and complaints frequently recurring about this.
    - detaro 2y ago
      But that's my point, what are these metrics that supposedly don't show the contributions anymore? Because the (IMHO) important ones all still show it, because they go by commit authorship in the repo, so you still get listed in the important places and can point to them.
      - throwanem 2y ago
        Well, fair enough: as I said, I don't know. The commenter with whom you originally raised the question can probably answer better there.

throwanem 2y ago

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.

mathstuf 2y ago

> I thought maintainers can edit pull request? Why is that not used here? I don't know if Github has it, but GitLab supports "push options"[1] where you can say "skip CI". There are other mechanisms, but they stay in the history since they live in the commit message (and the summary of all places!). Github seems allergic to any features that are mostly useful to "rewrite history" workflows though, so I wouldn't be surprised if that wasn't around. > Not pulling someones PR also means he does not get any public attribution to it. We use self-hosted GitLab and mirror on Github; I get boxes filled in on my Github account's grid and properly attributed in Github's stats despite only ever showing up there via `git push` commands. [1]https://docs.gitlab.com/ee/user/project/push_options.html https://docs.gitlab.com/ee/user/project/push_options.html