> Once I figure out how… I will try to submit a pull request. I wish I understood git better, but in spite of your help, I still don't have a proper understanding, so this may take a while.
Nitpick, but GitHub pull requests (which are
really merge requests, you aren't pulling anything) are named after the actual pull requests used eg. between kernel maintainers. ("Please, could you pull from ...")
I guess it might be more accurate for me to think about pull requests as Github's reification of the social protocol of pulling among kernel developers.
The culture around p.r.s is truly a high barrier of entry for many people.
Figuring out how all of this works is substantially more difficult I find in practice than fixing many longstanding trivial bugs in a great deal of software.
What’s the alternative? The old way (which is still used by many projects) is to send patches to mailing lists, which I find more difficult: you need to learn how to generate the patch from your source code repo, send the patch as an e-mail (needing weird hacks like `git imap-send`), and then configure your MUA not to mangle it somehow. Then you also don’t have a centralized search/tracking interface.
Some good reasons not to use GitHub is because you’re familiar with standard/traditional tools, or because you prefer not to use centralized services. Both of those are fine reasons! But “the traditional way is easier” isn’t.
Seems like you're arguing against something they didn't say.
They just said, "The culture around p.r.s is truly a high barrier of entry for many people." That's true and it's important to acknowledge that on any project that wants contributions from as many people as possible. When I was at Code for America I saw smart people putting plenty of time into helping people get over that barrier.
That's certainly the case here. If a professor of CS receives help from an open-source maintainer who's been coding for decades and still doesn't feel confident, then it's safe to say a) there's room for improvement, and b) until we figure out what the improvement is, we should make sure that we're providing the necessary support to everybody we want to contribute.
An alternative universe: you have an email you can send patch files too. You send the patch file (like, gen a patch file and then just manually attach that to an email). That automatically creates a PR looking thing.
The fact that (for example) GitHub requires a fork for you to send a PR to a project (that you don’t have push access to) is soooo overkill.
I mean… you can imagine a history being stiched together serverside. The ingest mechanism isn’t the final result. Just that “have to make a PR, have to make a branch name, etc” feels a bit silly
> I mean… you can imagine a history being stiched together serverside.
And since Git has a builtin mechanism for tracking such things, called branches, we could ask users to create a new one. Then add a possibility for people to comment on the proposed change. Sounds like you're incrementally reinventing PRs.
One would no even need to make a diff in theory, simply the new version.
In many cases, it is sufficient to simply send an email with:
> There's a bug in the function `handle_request` in `src/network/core.rs` that can cause it to return a double answer when invoked during a leap second. This fixes that issue: ...
And just include the new function inside of the email body, without attachment.
That should be sufficient for many cases, but many projects do not allow this and demand p.r.s.
Even Kernighan struggles with git.