23 ms·

While I agree that Github has made it easier, it is still not easy. First they will reject because of some subtle formatting error. Then they will reject becaus

by zumda 16y ago

While I agree that Github has made it easier, it is still not easy. First they will reject because of some subtle formatting error. Then they will reject because you didn't document it enough (or wrong). Then they will reject because your tests aren't done the way they do it. Then they refuse it because you merged and didn't rebase. There are hundreds of reasons why they won't pull your changes. This doesn't apply to small, single dev programs. They are usually, at least in my experience, pretty happy that someone wrote a patch, but the big ones are really, really bad.

pilif 16y ago
I'm happy if the upstream project is concerned with the quality of commits going into their software. That makes sure that the software will work great and it'll be easier to fix a bug in the future (if the history is reasonably clean) Basically, if upstream doesn't accept your patch, you have two options: Either you really want to see your patch upstream. In that case you invest the time it takes knowing that your contribution will be measured by the same scale that everyone else's contribution has been measured with. You also know that your contribution will be usable and part of a stable project. And you'll be confident that it probably won't be your mistake taking hundreds of sites down that are using the project you contributed to and are now hitting a bug you introduced. On the other hand, you can feel that it's not worth the hassle. That's totally fine. You'll just have to manage your patch on your own from now on (in the end maybe creating an even bigger hassle in the long run). Git gave you a very nice toolset for merging patches to an externally updated project, so that should be way easier than it was in the SVN days. What Github did was to actually make it possible to decide either way. Before Git and Github, your options were to either have it integrated upstream or to be stuck with whatever version you were patching (due to severely lacking merge support)

by zumda 16y ago

pilif 16y ago

I'm happy if the upstream project is concerned with the quality of commits going into their software. That makes sure that the software will work great and it'll be easier to fix a bug in the future (if the history is reasonably clean) Basically, if upstream doesn't accept your patch, you have two options: Either you really want to see your patch upstream. In that case you invest the time it takes knowing that your contribution will be measured by the same scale that everyone else's contribution has been measured with. You also know that your contribution will be usable and part of a stable project. And you'll be confident that it probably won't be your mistake taking hundreds of sites down that are using the project you contributed to and are now hitting a bug you introduced. On the other hand, you can feel that it's not worth the hassle. That's totally fine. You'll just have to manage your patch on your own from now on (in the end maybe creating an even bigger hassle in the long run). Git gave you a very nice toolset for merging patches to an externally updated project, so that should be way easier than it was in the SVN days. What Github did was to actually make it possible to decide either way. Before Git and Github, your options were to either have it integrated upstream or to be stuck with whatever version you were patching (due to severely lacking merge support)