4 ms·

The majority of git users I know don't know how to create or apply a patch. The few that do only do so in the odd FOSS project that requires it. Whereas when u

The majority of git users I know don't know how to create or apply a patch. The few that do only do so in the odd FOSS project that requires it. Whereas when using Github you click a button, get your own copy, do whatever you want to it, and then click a button to open a pull request. You _tried_ to make it look like using GitHub.com is somehow... complicated. But it's dead simple and you even added steps, like "waiting for PR to merge" etc that is the same with a mailing list anyway. I get it. You might like the mailing list better to avoid a single company handling all of the OSS contributions. But let's not ignore the actual good aspects of github by making up stuff. If you want to convince people to _not_ use github it's going to take more than this.

colbyrussell 7y ago
> You might like the mailing list Wrong. I fucking hate mailing lists. > You _tried_ to make it look like using GitHub.com is somehow... complicated. Please actually point out how the GitHub workflow can be even more simplified than what I outlined above. > But it's dead simple and you even added steps, like "waiting for PR to merge" That's not an added step. It's a necessary precondition for the following step (which I even acknowledged is optional!) If you can actually show, in a concrete way, that I'm using some form of Hollywood accounting and things can be made simpler than what I described, then please do. Every time this conversation comes up, we end up with a dead end when no one is willing to move past (or come up with some concrete support for) their argument that GitHub is "easier". But you've _already_ confirmed that things worked exactly as I described them.
- rhizome 7y ago
  The silent GitHub army is out in force today.
- Monotonic 7y ago
  > Please actually point out how the GitHub workflow can be even more simplified than what I outlined above Adding a remote is generally a one-time cost and is unneeded for every PR, so adding that command (along with all the associated comments) makes it appear more complicated. The reality for most GitHub users is that they simply have to do: `git push origin <branch name>`
  - colbyrussell 7y ago
    You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. > Adding a remote is generally a one-time cost It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
    - Monotonic 7y ago
      > You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to. > It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to. It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay both N times, where N is the number of projects you contribute to.
      - colbyrussell 7y ago
        > you can almost always push to origin Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project. > It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to. In other words, it's not a constant cost.
        jjeaff 7y ago
        >why am I having to repeat myself here Because you are incorrect and not reading the responses. >you set origin to the branch you own...
        deleted 7y ago
- esrauch 7y ago
  Can you clarify the flow that doesn't involve github and also doesn't involve mailing lists?
  - snazz 7y ago
    You could upload the .patch to something other than GitHub.
    - colbyrussell 7y ago
      Yes, exactly. Literally anything that has an upload button in the bugtracker for you attach your patch that fixes the bug.
    - moosingin3space 7y ago
      Can't reply to the sibling, so replying here. Mozilla used to work that way (upload patch to Bugzilla), but it was so cumbersome they switched to Phabricator.

colbyrussell 7y ago

> You might like the mailing list Wrong. I fucking hate mailing lists. > You _tried_ to make it look like using GitHub.com is somehow... complicated. Please actually point out how the GitHub workflow can be even more simplified than what I outlined above. > But it's dead simple and you even added steps, like "waiting for PR to merge" That's not an added step. It's a necessary precondition for the following step (which I even acknowledged is optional!) If you can actually show, in a concrete way, that I'm using some form of Hollywood accounting and things can be made simpler than what I described, then please do. Every time this conversation comes up, we end up with a dead end when no one is willing to move past (or come up with some concrete support for) their argument that GitHub is "easier". But you've _already_ confirmed that things worked exactly as I described them.

rhizome 7y ago
The silent GitHub army is out in force today.
Monotonic 7y ago
> Please actually point out how the GitHub workflow can be even more simplified than what I outlined above Adding a remote is generally a one-time cost and is unneeded for every PR, so adding that command (along with all the associated comments) makes it appear more complicated. The reality for most GitHub users is that they simply have to do: `git push origin <branch name>`
- colbyrussell 7y ago
  You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. > Adding a remote is generally a one-time cost It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
  - Monotonic 7y ago
    > You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to. > It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to. It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay both N times, where N is the number of projects you contribute to.
    - colbyrussell 7y ago
      > you can almost always push to origin Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project. > It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to. In other words, it's not a constant cost.
      - jjeaff 7y ago
        >why am I having to repeat myself here Because you are incorrect and not reading the responses. >you set origin to the branch you own...
        deleted 7y ago
esrauch 7y ago
Can you clarify the flow that doesn't involve github and also doesn't involve mailing lists?
- snazz 7y ago
  You could upload the .patch to something other than GitHub.
  - colbyrussell 7y ago
    Yes, exactly. Literally anything that has an upload button in the bugtracker for you attach your patch that fixes the bug.
  - moosingin3space 7y ago
    Can't reply to the sibling, so replying here. Mozilla used to work that way (upload patch to Bugzilla), but it was so cumbersome they switched to Phabricator.