> 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.
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.
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.
Because you are incorrect and not reading the responses.
>you set origin to the branch you own...
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.
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", 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.)
The origin you push to is your fork of the project.
Fork, push, pull request.
1. 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.