4 ms·
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 a
by rtpg 4y ago
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.
- bzxcvbn 4y agoWhat happens if multiple people contribute on the same PR (which is extremely common)? With a patch, that history is lost.
- rtpg 4y agoI 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
- sargstuff 4y agoOh, thought being told to git solved the conflicts.
- bzxcvbn 4y ago> 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.
- rtpg 4y agoBut _we don't need to ask users to do this_. We can just do "the obvious thing". 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-requests-and-how-to-fix-them/ https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-...
- Blikkentrekker 4y agoOf course not, the email can list the contributors, or not as it's own pleasure.