On Thu, Mar 12, 2015 at 8:35 PM, Michael Sloan
These weaknesses of github are pretty much only present when you are rebasing / force pushing the review branch. What do you mean by "no patch history"? The old commits are still visible, along with their comments. What is wrong with the comment system? I get notifications for comment replies, so I haven't experienced them being hidden.
Compared to a system like Gerrit or Phab: * you don't have a list of chronological state of the branch with comments attached to them while not hiding old commits once a branch fixup was applied. there's nothing wrong with rebasing a branch and viewing a branch as a patchset is the right and proven thing to do for anything nontrivial and small * comments made in old commits are preserved but collapsed and if it's collapsed you have to make an effort to find it in the github web page once there's a new reply to the old (now hidden) comment * there's no clear hierarchy like say "these comments belong to this patch state (aka branch state/rev)" * comments made in commits aren't even picked up in the pull request but only visible if you load the commit itself * it's pretty much chaotic and they focus on syntax highlighting and emojis as features sadly or so it appears
In my experience, the PR system works fine. Certainly worse exist, personally I've had quite bad experiences with gerrit. I realize that Torvalds himself takes issue with it, but it seems to work just fine for all the haskell projects on github (it seems like the majority of them). Is a philosophical issue like this really a good reason to ignore the positive network effects of hosting on github? People are familiar with github, and so this lowers the barrier to entry.
People use github and make do with its review system because only few and between have used a tool like Gerrit or Phabricator for reviewing code. You may find some insight in the recent golang blogs about this very issue. The reality is that projects tolerate and work around the problems and use Github because of the social network effect and less because the review system works. Like everybody else who's used something more logical/capable I can live with it, but it's up there with many things out of my control that are unbearable which I have to tolerate because I cannot fix it myself. It's similar to going back from Haskell to C and losing all the expressiveness features that aid in writing correct code. Now Xmonad is not a project that can change this by making a point and for instance Golang folks or Mozilla would have had to be more vocal and critical of it to achieve mindshare and change. We may use Github but we must point out bugs and not accept their model as the_truth if there's a proven better model of working with patches. If more people complain about it they may do something about it, but as I said if you don't know how other tools work better you don't see the bugs as easily. I wish we had distributed issue tracking but there's just Fossil's system that's production quality.
The hub tool helps quite a lot with reviewing PRs: https://github.com/github/hub It allows you to easily checkout a PR simply by copy pasting its URL.
It doesn't solve the broken code review system.