> 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.
Even Kernighan struggles with git.
Even Kernighan struggles with git.
Pull requests are feature of GitHub, not a part of git.
https://docs.github.com/en/pull-requests/collaborating-with-...
Git has tooling to help with those, so it kinda is a git feature: git request-pull. https://git-scm.com/docs/git-request-pull
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.
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.
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.
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.
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.
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.
We're talking about usability here, of course the fundamental features are available in Git. It's Git!
Here [0] is a more well written out version of this idea (by a developer of Mercurial).
[0] https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-...
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.