5 ms·

> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a pers

> For me as a person who learned programming in the times of Github/lab/whatever, the idea of sending patches via email is fucking ridiculous. For me as a person who learned programming before the Internet was a thing, and has worked both on projects that do patches by email and on projects that use web-based pull requests, I also prefer the web-based pull requests in every possible way. The email based workflow is baroque, painful both to send and to receive, lacking in features, and error-prone.

LudwigNagasena 3y ago
I would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.
- JoshTriplett 3y ago
  Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.
mariusor 3y ago
I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way. So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code. I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it. Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.
- madeofpalk 3y ago
  > I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it? For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
  - mariusor 3y ago
    I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context. I can of course do the same with the PR, but then it loses its convenience. :)
    - sdht0 3y ago
      > I can of course do the same with the PR, but then it loses its convenience. :) Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.
- ezst 3y ago
  > I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want. I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that. At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
  - 3y ago

LudwigNagasena 3y ago

I would prefer `git request-pull etc` to actually make a pull request that anyone could see inside their editor, on GitHub, in their mailbox or wherever else they want.

JoshTriplett 3y ago
Hopefully federated forges will make that easier, since it'll be easy for anyone to interface with using whatever technology they prefer.

mariusor 3y ago

I think we can all agree that the main reason why developers require distributed source control is in order to facilitate development in a parallel way. So, as a maintainer the purpose of such a request for collaboration (it being a PR or a patch) is to determine if: a) it does what it's expected out of it, b) it matches the conventions of the existing code. I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. The main issue with PRs (in my opinion) is that they limit severely the context in which the changes are viewed. If I want to properly review a piece of code I have to check it out and follow the diff in its proper context (either while debugging) or even while just reading it. Source forges, through the PR mechanism, encourage superficial reviews and insufficient attention being given to the merged code.

madeofpalk 3y ago
> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. How come? How is a text .patch file easier in this regard than a UI for essentially that same .patch? Can't you check out the PR in the same way you would 'apply' a patch to review it? For what it's worth, you can just add .patch onto the end of a github PR URL to get that.
- mariusor 3y ago
  I don't look at the patch by itself, I hoped that was clear. I apply the patch locally, where I have the full context. I can of course do the same with the PR, but then it loses its convenience. :)
  - sdht0 3y ago
    > I can of course do the same with the PR, but then it loses its convenience. :) Not at all. A PR still retains all the other useful features like separate threads for comments which be individually marked as done and CI checks. And not all PRs need a local checkout for a review.
ezst 3y ago
> I, personally, can make a judgement about both of things better with a patch that I apply locally than with a PR. FWIW, my git is configured in such a way that pulling from github also pulls all PRs for that repo, so, in effect, all PRs are applied locally, and I can review them however I want. I do think that email threads (when all parties are disciplined and have them properly configured) are superior to the PR+comments format for discussion, but applying patches from a mailbox has never seemed to me like a pretty and reliable way to go, so at least github helps with that. At any rate, git sucks for reviews in general because it still lacks mercurial's "mutable-history"/evolve approach to safe and distributed history rewriting (or "diffs of diffs"), and that, to me, is saddening as one more evidence that git's monopoly is causing stagnation and unnecessary pain in this space.
- 3y ago