3 ms·

> 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

> 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
        [deleted]
      - colbyrussell 7y ago
        Buddy, the entire premise here is user "Monotonic" telling me that configuring remotes is unnecessary and that that in fact he or she just pushes to origin. Don't jump in to the middle of the conversation here and then tell me that I'm not following along after saying to me that, in fact, you configure your remotes to be able to push to them. I know that! That you have to configure your remotes and that you can't just ignore it is _my_ position! The intense cognitive dissonance that comes out when GitHub is criticized on this site is friggin' _nuts_.
        danieldk 7y ago
        Buddy, the entire premise here is user "Monotonic" telling me that configuring remotes is unnecessary and that that in fact he or she just pushes to origin. They are referring to origin as the forked repository. E.g. if I contribute to nixpkgs (the NixOS package repository), I only have to fork it once, use that as my origin, and can create branches and submit PRs. So, you are both right. If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories. (I fully agree that GitHub has a lot of overhead compared to git format-patch/diff. GitHub et al. also have some benefits in terms of communication. At any rate, diff/format-patch are not that hard, so I think any git user should learn it.)
        colbyrussell 7y ago
        > If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories. That doesn't contradict anything I've written here, or anything I've written in years past on exactly this topic. But this _entire_ branch of conversation started with someone quibbling that I didn't rank configuration of remotes as a zero-cost operation. So, no, we're not both right.
- dmoy 7y ago
  Right, you set origin to the branch you own, and upstream to the original project. Then `git push origin foo` works, and you can get a URL printed directly on commandline to start the PR flow. I agree it's a cost per repo you contribute to. However, you can also do it reasonably cheaply with scripts. I recall you have to use hub in addition to git commandline, but once you get it set up then it's basically zero extra commands if you bake it into a clone. Run a script that does the fork to your github username and clone to your local box, do your normal modifications and commits, then git push origin and click on the URL to get dropped into the upstream PR workflow. The fork bit only needs to be done once.
  - colbyrussell 7y ago
    I feel like I'm in bizarro world here. I know that these things have to be done. That should be clear. Didn't I make it clear, in my rundown near the root of this conversation, that I'm aware of the existence of these things? My entire argument here is that it need not be done at all. That GitHub came along, made things _more_ complicated, and everyone's walking around with this idea in their heads that things are easier than they were before. Right? We had a process in two steps before. Now we have a process in seven steps OR something like three steps if you do enough bespoke automation on your local machine to smooth over these rough spots in the way that you mention. The infatuation with GitHub is so intense though that if you point this out, people flip the fuck out. Is it impossible to admit that GitHub made things more complicated?
  - Symbiote 7y ago
    > Right, you set origin to the branch you own That's surely equivalently complicated as adding a second remote. Almost every pull request I've made to a project on GitHub has started with a "git clone http://github.com/example/example.git" http://github.com/example/example.git", since they start with bringing down the source code and finding the bug in the project. Sometimes it's something I can fix, so I then need to fork the project on GitHub, add a remote (or replace origin with my fork's location), and make the commits. That's not too difficult, but it's not easier than sending a diff to a mailing list. If any discussion is necessary, it's easier to keep track of that on GitHub. It's also much easier to see the patch 3 years later, if the maintainer wasn't interested — that's the big feature which makes GitHub (or its competitors) worthwhile to me. (A long time ago I sent a patch to Git itself to the Git mailing list, and it was about 6 months before it was applied. However, it was applied, so they must have had some way of keeping track.)
- Jorge1o1 7y ago
  You do push to origin in a PR-based workflow. The origin you push to is your fork of the project. Fork, push, pull request.
  - colbyrussell 7y ago
    I'm going to try to make this as straightforward as possible: Where in this[1] comment does an error lie? Please make a copy and edit it to reflect what you're saying here and then show me the result. 1. https://news.ycombinator.com/item?id=19779664 https://news.ycombinator.com/item?id=19779664 I'm going to skip ahead here. You're going to replace the `add unnecessary-third-fork` command with `set-url origin $THIRDFORK`. Either that, or you swap for a `git clone $THIRDFORK` so "origin" is set as a result of the clone. How many steps do you need to eliminate before you can match the cost first sequence (2 steps)? How many steps does your advice eliminate? What are the total number of steps involved in the GitHub approach? I'll wait for your answer this time.

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
      [deleted]
    - colbyrussell 7y ago
      Buddy, the entire premise here is user "Monotonic" telling me that configuring remotes is unnecessary and that that in fact he or she just pushes to origin. Don't jump in to the middle of the conversation here and then tell me that I'm not following along after saying to me that, in fact, you configure your remotes to be able to push to them. I know that! That you have to configure your remotes and that you can't just ignore it is _my_ position! The intense cognitive dissonance that comes out when GitHub is criticized on this site is friggin' _nuts_.
      - danieldk 7y ago
        Buddy, the entire premise here is user "Monotonic" telling me that configuring remotes is unnecessary and that that in fact he or she just pushes to origin. They are referring to origin as the forked repository. E.g. if I contribute to nixpkgs (the NixOS package repository), I only have to fork it once, use that as my origin, and can create branches and submit PRs. So, you are both right. If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories. (I fully agree that GitHub has a lot of overhead compared to git format-patch/diff. GitHub et al. also have some benefits in terms of communication. At any rate, diff/format-patch are not that hard, so I think any git user should learn it.)
        colbyrussell 7y ago
        > If you contribute many times to the same repo, you only have to fork once. If you do a lot of drive-by contributions, you'll end up forking a lot of repositories. That doesn't contradict anything I've written here, or anything I've written in years past on exactly this topic. But this _entire_ branch of conversation started with someone quibbling that I didn't rank configuration of remotes as a zero-cost operation. So, no, we're not both right.
dmoy 7y ago
Right, you set origin to the branch you own, and upstream to the original project. Then `git push origin foo` works, and you can get a URL printed directly on commandline to start the PR flow. I agree it's a cost per repo you contribute to. However, you can also do it reasonably cheaply with scripts. I recall you have to use hub in addition to git commandline, but once you get it set up then it's basically zero extra commands if you bake it into a clone. Run a script that does the fork to your github username and clone to your local box, do your normal modifications and commits, then git push origin and click on the URL to get dropped into the upstream PR workflow. The fork bit only needs to be done once.
- colbyrussell 7y ago
  I feel like I'm in bizarro world here. I know that these things have to be done. That should be clear. Didn't I make it clear, in my rundown near the root of this conversation, that I'm aware of the existence of these things? My entire argument here is that it need not be done at all. That GitHub came along, made things _more_ complicated, and everyone's walking around with this idea in their heads that things are easier than they were before. Right? We had a process in two steps before. Now we have a process in seven steps OR something like three steps if you do enough bespoke automation on your local machine to smooth over these rough spots in the way that you mention. The infatuation with GitHub is so intense though that if you point this out, people flip the fuck out. Is it impossible to admit that GitHub made things more complicated?
- Symbiote 7y ago
  > Right, you set origin to the branch you own That's surely equivalently complicated as adding a second remote. Almost every pull request I've made to a project on GitHub has started with a "git clone http://github.com/example/example.git" http://github.com/example/example.git", since they start with bringing down the source code and finding the bug in the project. Sometimes it's something I can fix, so I then need to fork the project on GitHub, add a remote (or replace origin with my fork's location), and make the commits. That's not too difficult, but it's not easier than sending a diff to a mailing list. If any discussion is necessary, it's easier to keep track of that on GitHub. It's also much easier to see the patch 3 years later, if the maintainer wasn't interested — that's the big feature which makes GitHub (or its competitors) worthwhile to me. (A long time ago I sent a patch to Git itself to the Git mailing list, and it was about 6 months before it was applied. However, it was applied, so they must have had some way of keeping track.)
Jorge1o1 7y ago
You do push to origin in a PR-based workflow. The origin you push to is your fork of the project. Fork, push, pull request.
- colbyrussell 7y ago
  I'm going to try to make this as straightforward as possible: Where in this[1] comment does an error lie? Please make a copy and edit it to reflect what you're saying here and then show me the result. 1. https://news.ycombinator.com/item?id=19779664 https://news.ycombinator.com/item?id=19779664 I'm going to skip ahead here. You're going to replace the `add unnecessary-third-fork` command with `set-url origin $THIRDFORK`. Either that, or you swap for a `git clone $THIRDFORK` so "origin" is set as a result of the clone. How many steps do you need to eliminate before you can match the cost first sequence (2 steps)? How many steps does your advice eliminate? What are the total number of steps involved in the GitHub approach? I'll wait for your answer this time.