3 ms·

If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code

If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly. I just ran into this issue the other day when I was using Node with a lot of dependencies that still haven't been patched for issues that cropped up in OSX Yosemite.

jrochkind1 12y ago
> it's very difficult as a user to figure out which version I should be using for my code to run correctly. I've rarely had trouble with assuming master (or ideally a tagged release) on the original repo (not a fork) is the one I should be using. Assume all forks are forks. In any cases where this hasn't been true, it's been clear to me the blame is due to poor release management (or poor communication of release management, which is the same thing), rather than somehow the fault of github's PR or forking system. Although you can hypothetically argue that certain UI's encourage poor release management and others support it, I personally have not seen this to be an issue in github's UI.