3 ms·

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

by dmoy 8y 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 8y 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 8y 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.)

by dmoy 8y ago

colbyrussell 8y 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 8y 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.)