Gitmate is much more than just static code analysis and review suggestions. It supports automatic issue triaging, rebases, labeling, identifying human reviewers, and so on.
Here's an example code review: https://i.imgur.com/JO0nXL7.png
(Here's an example if there are 10+ reviews: https://i.imgur.com/VlQA9iS.png)
How is issue triaging related to code reviews? Trying to imagine how that is useful
It's not. I just wanted to mention that that's possible with Gitmate as well.
This table is our aggregated view that gets triggered if there's a lot of comments that would spam the PR.
The code review functionality is completely open source at code.gitmate.io FWIW.
We grew from the whole review thing into automation for PRs (setting lots of labels for PRs automatically, managing review queues; it's all in GitMate) and eventually started with issues. Our next step is to split the review and issues because this is becoming very hard to communicate marketing wise ;)
1) All accessible via a browser instead of Desktop App. 2) PRs are all queued up nicely and easily searchable in said browser instead of littered all over a folder in my email 3) PRs can have rules that don't allow merging without reviewers having accepted the change. CodeFlow seems to ignore this in my experience and 'required' reviewers are more just suggestions and people just check in their code whenever anyways.
It's entirely possible my team, myself included, don't understand how to properly use CodeFlow though so take my opinion with boat load of salt. Similarly, I'm sure my third issue could be fixed by improving our review process as well, rather than switching tooling.
It runs off a server inside your company, but you can try it out on open-source code on GitHub with the Sourcegraph Chrome extension: https://chrome.google.com/webstore/detail/sourcegraph-for-gi....
Not sure how feasible that is to implement transparently though. Seems to me at minimum it'd have to require developers to add some kind of annotation to the function to include a globally unique identifier (though I'd honestly be willing to put up with that in exchange for the benefits).
(To my eye Gerrit seems like it was written by people who wanted git to work like svn.)
The only plus is the integration with linters. beside that, "native" bitbucket/github/gitlab PRs are way better
git log --pretty=full --reverse --show-notes=* -p --abbrev-commit origin/master..
I've yet to see a tool that allows me to review all commits as well as code, as easily.
I don't only review a branch as a whole, i.e. `git diff master`, or "here's the diff" from a pull request… but I also review each commit individually (and rebase/amend them when required), as commits need to be in tip-top shape to end up going into master.
I have only used the installed version, not the hosted online version.
The basic PR structure is simple. Very much the same as in github.
In detail the implementation has several nasty defincies. They do not distinguish author and committer at all, which can lead to very misleading info on the screen if they are different
There are PR comments and line comments. Sometimes a file comment might be appropriate, but that does not exist.
The code viewer has limitations so I find myself using git difftool with meld or something like that in more difficult cases. Of course the difficult cases is where review and tool support would be needed most.
IMHO the biggest problem is that line comments are a one time thing lost in space afterwards. You need to know in which PR to look, actually even in which file version of the PR if the file has been updated during the review. There is no direct way to access previous review comments relating to certain code. Not sure if anybody else handles that better.
Regarding PR comments and line comments, file level comments have also been available from the beginning. There's a comment button above the diff view for this.
Regarding line comments being "lost", it's true that when they become outdated they can be harder to get to, but they're available. If you go to the activity tab all past comment threads are available to help make sure you've not missed anything. We're working on ways to show outdated comments in the diff view, and beyond that we're looking at adding more to our search capability for finding comments across pull requests.
For author and committer treatment, we do respect the two concepts in Git, but you're right that we don't display them clearly in the UI. We added coverage for returning both roles in the API back in 5.0, and at some point we'll probably update the UI to display it.
I'd love to hear more about what you feel is lacking in the diff view. We're doing some work there now so perhaps we can cover off your use case (or plan to already).
Rubberduck VBA - http://rubberduckvba.com/ GitHub - https://github.com/rubberduck-vba/Rubberduck
The parser is one of the most robust parsers for VBA available, and the code fixes and refactoring tools allow you to quickly apply suggested improvements. The parser is COM aware, so it will even analyze the in-house/3rd-party add-ins and libraries/controls that you use within your projects.
There's full support across all VBA hosts (Eg. Excel, Word, Access, PowerPoint, AutoCAD, SolidWorks, CorelDRAW, Publisher, etc) and soon, there'll be support for VB6.
The integrated add-in is feature rich, but there's also an online review tool at http://rubberduckvba.com/Inspections/List
The languages are wide and varied, the questions and answers are actively curated and moderated, the solutions range from the simple to the overtly complex. The support for code markdown is more than adequate, and of course, the StackExchange voting system helps bring the best questions and answers to the fore.
There's even an integrated chat system as part of the network, where mods, reviewers and questioners can collaborate and discuss issues.
The history of software has quite a few examples where software solves people problems