Does anyone know what code review system they are using with github?

"We will use a Google-hosted instance of Gerrit for code reviews."

thank you. Missed that in the article (was skimming >_> )

Me too, my brain is wired to read Gerrit as a common Dutch first name, so I thought he was talking about a person named Gerrit.

I'm curious what Gerrit gets them that Github doesn't have natively, too.

Go team member here.

I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot.

Github's review mechanisms barely scratch the surface of what's possible.

If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.

From best to worse, in my experience:

1) Google's current internal one

2) Gerrit (open source, to be used by Go)

3) Google's old one (Mondrian)

4) Rietveld (open source, but run for free at codereview.appspot.com)

5) Github

I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.

There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head:

- Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history.

- Pull requests require the contributor to create a public fork of the repository they're committing to. I can see how this works for some people, but I find it gross for each contributor to the Go project to have their own public fork. What a mess.

- Comments on pull requests are sent as soon as they are created. Gerrit allows you to make many comments on a change, as drafts, and then send them all in one go, sending just a single email. This is much easier to manage for a large project.

- Gerrit has the notion of multiple 'patch sets' for a particular change, and you can see diffs between patch sets, so it's much easier to progressively review large changes.

And there are many other small issues with the GitHub pull request process that make it untenable for the Go project.

Pull requests require the contributor to create a public fork of the repository they're committing to.

You can create Pull Requests within a repository. You don't need to fork the repository if you have push access.

I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go?

- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.

- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.

Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(

- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.

- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.

I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)

We're going to build a bot that replies to pull requests to the Go core. It'll say "Sorry, we don't take pull requests, but here's how to use Gerrit [link]. Thanks!"

Not to be flippant, but if you are not going to use pull-requests, what is the benefit of moving to Github? Will you use the issue tracking system?

If not then it just seems like switching to git using the present google code host would suffice from a technical viewpoint.

We will use the GitHub issue tracker, which will allow easy cross references between go issues and other projects on github.

I have to agree that not using pull requests is missing out on the best feature of github. It's the social, low-overhead way to contribute to a repo.

It seems like it must be possible to hook up a bot to github that watches for pull requests and submits them to gerrit... the Juju team has a bot that does that for our Reviewboard integration. It won't work for more complicated workflows that github doesn't support, like dependent branches or whatever, but it lowers the barrier of entry for initial contributors that just want to submit a simple fix. And the more advanced users can just submit directly to our Reviewboard instance if they want the more advanced features.

Also, the public fork on Github is actually a feature - it means others can easily see what you're working on. You need off-site storage for your personal work anyway, right? You're not going to keep it local on your laptop, so you'll need a branch somewhere regardless.

Nice summary; thank you. I don't know why people put up with the merge commit pollution. Great to see Go taking the best of both worlds.

The merge history is the true one, it's what you want when browsing backwards to see how particular things changed. Rebase creates fake commits corresponding to a tree that never actually existed anywhere. Your history viewer should be able to linearize the tree for you if you want, but the canonical history in the repository should be the true one.

That's just one workflow.

For Go, we will require that contributors (everyone working on Go) prepare their commit at head (or at least make the commit able to be automatically rebased). It makes no sense to have a merge commit for every single commit. That would add no extra information and double the size of the commit log.

I used to work at a company that did 100% of code reviews on gerrit, and by 100% I mean we had a requirement all commits be approved so I spent a lot of time in gerrit.

then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit.

gerrit makes it so clear what commits need reviews. in github it's just a list of pull requests. did I comment already? does this need approval? is this already approved by someone else? who? all of these are difficult to see in github but instantly obvious in gerrit.

then at the code level, gerrit uses my whole browser window so on a 30in I can side by side diff any file. GitHub has a tiny viewport and I'm constantly scrolling. it's not streamlined for reading at all and once 5+ comments are there you can give up on reading the code. gerrit has an upper limit on comments too before the ui overwhelms the code but it's way higher.

I think gerrits tools for viewing more lines are better, although phabricators are good. gerrit gives me a copy and paste link to check out exactly the code I am looking at.

and I really enjoy the patch set system over additional commits. it's a lot clearer in a back and forth setting to see code evolve over time and digging patches without making entirely new commits.

gerrit has built in support for automated and human reviews to leave separate scores. aka, you have to pass the tests and get approval. this doesn't exist in GitHub.

extending gerrit with hooks was crucial to our workflow. luckily github delivers there, but as gerrit is open source you can do more to extend it. especially on the ui side.

I have to admit at first I was blown away how weak github is compared to gerrit. I could not understand why it's so popular. now after about a year on github I get it, I get why it's popular, but is still years behind gerrit.

It is great to see so many projects moving to git and GitHub in particular. GitHub is incredibly helpful for quickly taking a look at a project and figuring out what areas of a project are still evolving and being actively developed.

You could also say that everyone moving to GitHub is leading to a dangerous centralized monoculture that evaluates software quality based on how well it fits GitHub's conventions.

git is still git - people don't even need a github account to have full functionality.

How many Github projects accept git format-patch submissions? There's functionality beyond the basic DVCS commands.

In Go's case, we will be using Gerrit (elsewhere) for accepting submissions. GitHub will only be used as a source code mirror, wiki and issue tracker.

Moving to git is great, moving to github can be terrible for some projects that are more collaborative, as if you want to change someones PR you cannot..

You can makes changes to a PR that you didn't open.

If you want to change the title, edit/delete comments, close the PR, assign a person or labels then you'll need the proper permissions.

If you want to make changes to the code you'll need to have push access to the same repo (which is usually the case if you're on the same team because then you don't need to use forks). Otherwise you can always amend the commit(s) before merging them into master.

Better still you can fork the PR and open a PR to the PR :)

This is a huge compliment to GitHub, for Google to be moving one of its premier open source projects off of Google Code and onto GitHub.

More importantly, though, this is a significant compliment to the Go community, for Go to uproot itself and move to where the majority of its users are.

The writing's on the wall for Google Code. I don't think I've seen a new feature in several years.

I'd love for them to just go read only, a TON of academic work lives on there, but its awful to use.

I much prefer Google code defect tracker to the GitHub one. But that's about the only plus of Google code.

(Though, a small part of me wants mercurial to live on, but it doesn't seem like that will happen)

Google Code = Google Video

GitHub = YouTube

Uh, no. Google Code took over the space in a way Google Video never did.

    SourceForge -> Friendster
    Google Code -> MySpace
    GitHub -> Facebook

:)

I think Google stopped bothering with Google Code when Github came to popularity.

Google Code doesn't really fill Google's mission, so it's not absurd for them not to bother once someone who's truly focused on the space has created a superior competitor.

Google Code was created mainly to combat the monoculture of Sourceforge, which was slowly growing crappier.

Google wanted to create a place open source people actually wanted to be, and had reliable hosting, instead of a place people had to sadly live with that was pretty unreliable (no offense meant to my friends at sourceforge).

Doing so jump started some competition in this space.

While github is slowly becoming a monoculture again, it doesn't appear to slowly be growing crappier or less reliable.

I'm sure in 5-10 years something like Google Code will be necessary again.

(Google code was the first engineering project I worked on at Google, for a few years starting in 2006).

Hi Dan! Remember when I DDOSed Google Code on Super Tuesday 2008, when I thought it would be a good idea to host my election map result tiles there, and then I forgot to turn off the cachebuster in my tile URLs? Good times... :-)

If they wanted to they could turn Google Code into a real competitor for Github with full GAE and Compute integration. That would make it an amazing platform.

Who says they won't? :)

Seriously though, yes, that would be really cool, but probably not something you could directly transform google code into. Google Code is a pretty legacy codebase in a lot of ways. It would likely require making a new platform to do such a thing.

Google hosting Go on GitHub. Microsoft hosting .NET on GitHub. It must feel like an accomplishment to be implicitly endorsed by these companies.

Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.

I'm impressed.

They've really made it easier to collaborate.

Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across.

It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.

You must have dealt with a completely different company and product. The public github is a lot better than the enterprise version at least in terms of stability. Still, both lack a lot of basic issue tracker and code review features.

Github enterprise was a disaster with just a couple hundred users.

Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had to reboot the servers constantly.

We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement.

They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view.

We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.

    > Still, both lack a lot of basic issue tracker and code 
    > review features.

I strongly disagree. What you might consider "basic features" I'd consider antifeatures. The bare simplicity of the issue tracker is precisely why I use it for my (large) projects. The PR model of code review scales elegantly to hundreds of contributors. I'd be devastated to see GitHub's collaboration tools move even a step toward the hellscape that is JIRA.

At least for code review, the problem isn't pull requests as-such. The features that drive me to use other tools (on top of guthub hosting, often) are things like:

* The ability to mark which commits/files have been reviewed and so track progress.

* The ability to distinguish resolved and unresolved issues

* The ability to assign a reviewer based on which code is being altered in the PR.

* Useful handling of history rewriting during review.

I also think that the PR model could be implemented in a way that would make for better collaboration. At the moment, if someone submits a PR that has some issues and you want to help them fix those issues it's a huge pain because the commits typically live in their fork to which others usually don't have push access. It would be a considerable improvement if PR branches were set up in such a way that both the original submitter and the people with commit access to upstream could push to the review branch.

Now we just need Apple's Objective C / Swift to move to github. :) Sorry, not going to happen. :(

Apple has stated that they're going to open source Swift in the future, who cares if they choose to host it on their own platform.

I haven't heard that they have announced a decision. Do you have a source for that?

I'll believe it when I see it; I'm still waiting for the promised open-source release of the Facetime protocol.

That was canceled due to a patent lawsuit. It would have cost apple a ton of money to pay a patent troll to be able to open source FaceTime.

http://www.bbc.co.uk/news/technology-20236114

To clarify. Because of this lawsuit, Apple moved facetime away from being peer-to-peer to now being routed through Apple's servers. Since they have to use the centralized model, opening up the protocol for others to use would also require using Apple's servers to play nicely. So Apple would be footing the bill.

Don't they have a mirror of the compiler on github?

https://github.com/llvm-mirror/clang

Swift hasn't been included but objective c is there.

Use go for a few month, loving it. but I miss not having exception compare to Python.

Is the golang spec still tightly controlled by 3 wisemen in Google and no feature is allowed to add to the language without all three in total agreement?

BTW, I like 98% of their language decide choices and absolutely LOVE the compilation speed of the program.

No, it's not controlled by them anymore. Possibly in the early days it was, but now it's much more community controlled.

You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types).

You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.

You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions

If by exception you mean Java's implementation, yes. If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no.

I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.

think most of this could be solved easily by either a compiler option or golint rule

You mean like errcheck? https://github.com/kisielk/errcheck

I'm not sure if it can find spots where people intentionally throw away an error like in

    val, _ := foo()

Usually people are more concerned with places where people accidentally fail to realize there's an error returned at all, like this:

    func foo() error { ... }

    foo() // errcheck finds this

However, it should be possible to find errors assigned to underscores, and thus detect that case.

Ideally that'd move into the standard suite and you'd have to do something like compile with --repeat-the-mistakes-of-c to skip it.

I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).

I agree. I almost think the name GitHub is unfortunate at this point: they're doing something so right they could nearly invent their own VCS, use ESR's new tool, or even switch to hg/darcs/etc, and still gain momentum. The Go community seems to be hopping onto a fairly heavy pendulum.

The best-engineered technology rarely becomes the most popular. I think git has some huge problems, but now it's ubiquitous. Everyone has at least a basic knowledge of it, and that makes it the best technology. Switching to something else would be a step backward.

What are gits huge problems and what other technology solves those?

Not trying to put you on the spot, just curious.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

There are countless git frontends (easygit and git legit) that come to mind, and yet they all see negligible use.

I think the cognitive load of using git is overrated. Yes, it could probably be simpler. No, you probably can't make simple and intuitive for everyone while retaining all the features.

Given that it's also easy to work with e.g. subversion or mercurial and a git bridge, so you can use the client of your choice with a git server, and yet no one seems to do that is an indication that git is sufficiently simple to use.

yet they all see negligible use.

Evidence? Using my own anecdotal evidence, I strongly disagree.

I checked volume for GUI-related keywords[1] against CLI-related keywords[2].

The GUI-related keywords get ~34,000 searches per month. The CLI-related keywords get ~4,500. My methodology and data aren't perfect, but it's something at least.

Your premises are:

    - People use tools that are sufficiently simple.
    - People use git CLI instead of git GUIs.

And your argument is:

    - Git CLI is sufficiently simple.

Your first premise is just wrong. People use complicated things all the time because they don't know about simpler things. People also often think things are simple and then use them wrong. In my experience, a LOT of people use git wrong/dangerously.

I've addressed your second premise above. There isn't (and may never be) good data there, though.

[1] git gui; smartgit; git client; git tower; github gui; git frontend

[2] git command; git "command line"; git cli

The git CLI is a mess. It's inconsistent even within its own commands. For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch".

It even uses different words for the same thing - sometimes remove, sometimes rm sometimes -d.

Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".

The reason people don't use other git frontends is that a vast majority of the help topics already out there only reference git itself. So if you want help for rebase, for example, if you're using some frontend that re-kajiggers the command line, all that help is now useless, or even worse, potentially downright incorrect.

For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch".

AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository.

git merge, on the other hand, is simply "git merge ref"; when ref is of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network.

So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git.

Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".

Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".

Emacs moved to GitHub as well :)

Emacs recently switched to git. Emacs did not move to GitHub. There is a mirror repo but Emacs itself is not on GitHub.

Another monopoly in the making: "github cuz everyone is on github".

"facebook 'cause everyone is on facebook."

It's the same effect.

There are only two things that are going to fix it - either something amazingly better comes along (facebook vs myspace) or the incumbent royally screws up (reddit vs digg).

To be fair, it's not entirely the same sort of thing. Git is an open protocol. Github just happens to be one of many sites hosting git repositories. Moving a repository to another host is trivial; you already have all the data in your local tree.

Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperating with other social networks.

Am I the only one who thinks some more competition would be nice? I would like to see more code move into BitBucket or similar. New version of Kiln will make it possible to use Git and Mercurial against the same repository which sounds like a great feature (not sure if there is a free plan on Kiln yet).

You are not the only one. We finally have decentralized tools only to... put all the eggs back into one basket!

I think this is Google quietly admitting that Google Code is all but dead. They will not completely get rid of it, but I would not be surprised if they switch it to read only mode sometime soon.

This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long time.

Kudos to the Github team for well and truly making it as the premier code hosting and collaboration tool for developers and lovers of open source. It only goes up from here.

Admitting Code is going nowhere, and seemingly for the first time in living memory, playing geek marketing catch-up with Microsoft :) I really love the new MS.

As someone has already mentioned Google already has stuff on Github.

Dart: https://github.com/dart-lang

And lots of other stuff:

https://github.com/google

Not limited to Google's main account, there is also Angular.js, Polymer, and CCA, to name a few others.

CCA?

I think this is Google quietly admitting that Google Code is all but dead.

Go was on Mercurial before so it was already away from any Google own source control system.

Go was on Mercurial before so it was already away from any Google own source control system.

How being on Mercurial implies that it was "away from Google code" ? It is in fact hosted on Google code currently (https://code.google.com/p/go/)

PS: Google code supports: subversion, mercurial and even git (https://code.google.com/p/support/wiki/GettingStarted#Workin...)

I think this is Google quietly admitting that Google Code is all but dead.

Well, I doubt that Google Code engineers or project managers had much, if anything, to do with the decision to move the Go project.

That they didn't have a say in this matter though, speaks volumes...

It would if the whole idea wasn't based on an assumption with no evidence.

If they were smart about Google Code they would update it significantly and make it a competitor to Github with full GAE and Google Compute integration.

Google Code has a really bad user interface. This migration makes sense. I wish they stuck with Mercurial and moved to Bitbucket instead, but Github is still better than Google Code.

As someone who uses Ruby as my primary language; I'm totally jealous of this move. While there is a github mirror, it sucks having to use Subversion for the "one true repo" when everything else I work with these days is on git.

I contributed to Ruby once by issueing a pull request to the GitHub mirror, it went fine. Is it less handy if you're a regular contributor?

Now all we need is Jeff Bezos to buy Github :-) That would be funny.

But on the story this is a great move, Github is much nicer than Google Code and more actively supported. I had not heard of Gerrit before and that was a really pleasant discovery. Now to figure out how to get that setup at the office.

Gerrit is an absolute treasure of a tool. I shudder everytime I make a pull request in Github because Gerrit's contribution model is so much better for my workflow.

I guess its official, misogyny is ok in our industry.

Have we forgotten about: http://lmgtfy.com/?q=github+misogyny ?

I'm not sure github even experienced a dip in traffic.

There are github alternatives, it took me 30 minutes to remove my github subscription and migrate my repos to bitbucket.

I will bite.

How does using Github even remotely contribute to accepting misogyny in our industry?

I will bite back.

Github's corporate culture appears to be very anti-woman. There is plenty of available evidence to this effect. There is very little apparent diversity (of any sort) in their large team. https://github.com/about/team

Using Github contributes to the success of this monoculture and encourages tech leaders to revere and duplicate this model. It makes tech more difficult for people outside of that group - the white, straight, male group. It makes tech culture worse.

If I'm aware that you host on Github, I will make sure to consider what your competitors are doing before I use your service.

I can see how you could make it a valid argument like that. Thanks for elaborating.

Do you think that not using services from companies with a monoculture is the most effective way of furthering the cause? I'm all for more diversity in the technology and startup sector, but I do believe that the cause should, and eventually will, be solved by dialogue and focus on the issue - not by silently boycutting the companies. Or am I missing some part of the picture?

Github promoted misogyny internally. You give them revenue, allowing them to continue to run their business. Ergo, you are promoting the misogyny Github promotes* internally.

* The burden of proof that Github doesn't promote misogyny is on Github.

EDIT: I personally use Github, but I cancelled my account after what happened. For new projects I use bitbucket. I actually feel bad when I'm using Github precisely because to a degree it means I'm promoting misogyny.

Have you assessed Atlassian's culture and concluded its constituents promote gender equality?

http://www.dailymail.co.uk/news/article-2649354/Australian-t...

Does boycotting Github for the rest of time over a scandal achieve anything?

Nonetheless, your post has value in that I'm now thinking about gender equality in technology. Thank you.

I think these are two separate issues:

  1) Go is moving from Google Code to Github
  2) Go is moving from Mercurial to Git

To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, there really isn't much difference between the two (too bad GitHub only supports git though).

I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.)

This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.

Hi Go team,

if you want an alternative for Gerrit code review, you can also use http://review.ninja. It's also open source, so you are welcome to contribute.

Cheers, Mitch

Took a brief look at the front page.

- No side-by-side diffs? Didn't see any in screen shots.

- The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a deal... In any case, the scary scope list prevented me from experimenting.

Hi skj!

- What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit.

- Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permissions in the first place.

Thank you for the feedback!

Review Ninja is beautiful, but at it's core, it's just slightly more nice stuff on top of pull requests. It can't address the issues such as being able to edit someone else's pull request as part of a code review, can it?

How much do we have to bribe you for Bitbucket integration?

The world today is quite different from the world then.

Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.