Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I really like the idea of merge conflicts being resolved in the open in a pull request, instead of the pull requester working in seclusion. For those of us with projects on GitHub, is there any way to replicate this behavior there?


A common practice is for pull requesters to rebase their branch on the upstream branch to avoid these conflicts.


But if the master/upstream is changed, the feature branch must be updated again (manually).


There is no magic to avoid this problem. If you are trying to get changes into a repository that is constantly changing with no good isolation of concerns, then expect pain.

Otherwise, merges really are better from most perspectives. I can trust people doing pull requests to have tested their code. Looking at the log, I can get an idea of whether or not their code was tested with someone elses. Something I can not do with a pure "rebase and push" mentality.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: