[alderz]

By reading the stream of comments on the PR, and from my own experience, I feel that it is extremely cumbersome to do code reviews on Github. Atlassian's Fisheye/Crucible looks like a better solution. Does anyone think otherwise? I think Github has a large room of improvement in this regard; a PR is not the same as an issue.

[ahnick]

On GH I can see the files that are changed and make/read comments that are inline on the files as well. This has been sufficient for my needs. What is it that Fisheye/Crucible brings to the table that you think would be desirable on GH?

[alderz]

I guess that for some people, and particularly in small reviews, it is enough with the list of files and inline comments.

I would like to have a tree view where I can see all the files at a glance, and, more importantly, switch back a forth between them. I find it hard to follow the code in Github's UX.

Also, Fisheye/Crucible gives you more flexibility to edit the review, by allowing you to remove files, and add or remove commits. Github PRs are based on branches, while Fisheye/Crucible code reviews are based on commits; it is an entire paradigm shift that gives the user more control. For example, I can create two separate reviews from the same branch on Crucible; that's impossible on Github.

[ChrisMarshallNY]

I don't feel like GH is really meant to be a code review platform. It does PRs, but I assume that review should be done offline (like in other tools, like Crucible).

We have used GH as a review platform for an open-source project, but they tend to be relatively minor PRs. If they got hairier, we'd probably find something else.

Personally, I really don't like having a gazillion different tools. If we can use one tool for several purposes, then that's what I prefer. If the tool becomes too cumbersome, then I'll work with something more specialized.

[aspenmayer]

Is there a good self-hosted open source platform for this? I’m new to all this, even though I’ve been computing since I was in grade school. Coding is a new discipline for me, and it’s hard to know the territory without a guide. I’ve seen you around and would trust a recommendation from you.

[emmelaich]

I suggest https://www.gerritcodereview.com/

[aspenmayer]

Thank you, I’m going to look into this more.

[skrtskrt]

I have used and enjoyed Upsource (JetBrains code review tool) particularly for trunk development where you often need to be able to cherry-pick randomly-ordered commits into a review.

I honestly don't know how much our org paid for it though.

[MaxBarraclough]

You might be interested in Torvalds' low opinion of GitHub pull-requests.

https://github.com/torvalds/linux/pull/17#issuecomment-56599...

Discussed at:

https://news.ycombinator.com/item?id=3960876

https://old.reddit.com/r/programming/comments/tionj/

[momothereal]

I've been using GitHub for code review (both open-source and commercial projects) for about 5 years. It's improved a little bit, but for PRs with >100 files changed it's obviously lacking good UX.

For me, the biggest improvement would be the tree-view you get in Fisheye/Crucible. It's so hard to get a grasp on large refactoring PRs on GitHub.

[outadoc]

This extension [1] makes code reviews more bearable, I highly recommend it. I don't understand why Github hasn't shipped this years ago. They've been improving the UX since their acquisition but there's still a long ways to go.

[1]: https://addons.mozilla.org/en-US/firefox/addon/better-pull-r...

[the_af]

I wonder how one does manage a PR with >100 files changed. I realize these are sometimes unavoidable, but shouldn't we strive for smaller PRs? No tool will help you with exploding complexity...

[fotta]

Usually with massive PRs of that sort I’ll have several smaller PRs to a separate branch that get reviewed so that everything in the massive PR to the main branch has already been reviewed and the big one is just a cursory look. But this approach probably isn’t as feasible with open source projects.

[dathinab]

It's not just git. I have yet to see a platform which does PR code reviews in a way I like.

If it's small PR or PR's from trusted sources it's not an problem but once it's bigger and from a third party reviewing it can easily become much more annoying then it should.

Besides UX aspects on major offender IMHO is the text based diff algorithm. I had to often changes where you could have created a easily readable diff but non content aware git diffs just produced total garbage.

[lmm]

I spent four years working at a company that uses stash/"bitbucket server". Coming back to GitHub I was shocked at how much worse their PR workflow is.

[berkut]

I agree whole-heartedly (against both Github and Gitlab code reviews for serious large changes), but from what I've heard Crucible is apparently EOL now?

[secondcoming]

Agreed. We moved to GH from Bitbucket and code reviews is the only thing that Bitbucket did better.