4 ms·

Indeed. A pull request is indeed a ... request to pull changes! One fetch/apply later you can use your local merge tools to evaluate. I guess the various hubs,

Indeed. A pull request is indeed a ... request to pull changes! One fetch/apply later you can use your local merge tools to evaluate. I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.

_ikke_ 4y ago
The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.
- mariusor 4y ago
  I think that at least for this specific use case the would be PostmarketOS contributors have access to Gitlab. Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
- GoblinSlayer 4y ago
  The idea is that centralized host doesn't imply centralized development model. You already have five centralized hosts for that matter.
- cxr 4y ago
  Well, no, that's putting the cart before the horse. Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden. * And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
  - Jasper_ 4y ago
    What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.
    - cxr 4y ago
      I'm responding to the claim that GitHub solved the problem of everyone needing "infrastructure to let others pull directly from their repositories". What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
  - twic 4y ago
    It is truly weird to me that the standard workflow for submitting a change to someone's project is now to make a copy of their project, change it, and then ask them to import your change. This is inside-out and upside-down! Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
    - rakoo 4y ago
      Exactly what sourcehut does

_ikke_ 4y ago

The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.

mariusor 4y ago
I think that at least for this specific use case the would be PostmarketOS contributors have access to Gitlab. Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
GoblinSlayer 4y ago
The idea is that centralized host doesn't imply centralized development model. You already have five centralized hosts for that matter.
cxr 4y ago
Well, no, that's putting the cart before the horse. Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden. * And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
- Jasper_ 4y ago
  What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.
  - cxr 4y ago
    I'm responding to the claim that GitHub solved the problem of everyone needing "infrastructure to let others pull directly from their repositories". What are you talking about? (The general tone suggests that you're refuting something about my comment. What part are you trying to refute?)
- twic 4y ago
  It is truly weird to me that the standard workflow for submitting a change to someone's project is now to make a copy of their project, change it, and then ask them to import your change. This is inside-out and upside-down! Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
  - rakoo 4y ago
    Exactly what sourcehut does