Folks, this is why you want to do code reviews inside your editors / IDEs. I like this project, but really what they did is build a read-only version of an IDE from the ground up. You already have one and you know it inside out.
I've found, as the OP did, that the GitHub/Lab/Bucket code review UIs strongly encourage nitpicking over code style and strongly discourage true insightful reviews on a design and architecture level. This happens simply because of the amount of effort your have to do to see and feel the wider impact of a pull request on your codebase. It's like looking at code with blinders on.
So what you want to do is checkout the pull request and use your editor. We made this a habit here at TalkJS and the quality, speed and usefulness of our code reviews skyrocketed.
Actually we take it one step further: we dropped the commenting interface altogether. Our code reviews are commits, with code comments by a particular format:
// REVIEW(marcin<-egbert): Won't the event listener get re-registered every time this function is called?
My colleague Marcin can find all reviews intended for him by grepping for `REVIEW(marcin`. Git ensures that even across merges and code changes, comments stay put, and once Marcin applies the review comment he removes the comment. He can reply by adding a comment in the same format.
The fact that review comments are right there in the git history also really helps track down complicated problems. Finally, we get the freedom of merging a PR anyway even though some things ought to be better, without losing track of the review comment. Obviously that's a code smell, but sometimes it's better to release first and refactor next day.
But even if you think this is insane and reviews don't belong in the code, I'd like to warmly encourage you to use your editor for reviews.
I'm still seeking a good way to do reviews/merges with Vim though. I use a Macpro Ret 13" and it nicely fits two ~80char windows. However, three windows as vim normally does for merge conflicts/etc is too much for the 13" screen, it ends up cluttered and cramped.
Anyone have any recommendations for how to efficiently handle conflicts/reviews via vim with a small screen?
I am surprised that your highres screen doesn't handle three buffers side by side. My 13" 720p laptop also has trouble with three buffers, but I was hoping that would be mitigated the day I got a highres 13" laptop.
Anyways, you can try a narrow width font: I love M+ 1mn, though the narrow width causes problems when it doesn't have a certain unicode point defined and falls back to a full width font..
Yea, it's likely a font issue. This[1] is what my font looks like, which is quite readable to me but i can't get much smaller (for me personally). Each pane fits ~85 chars (not including the vim sidebars/etc), so it's quite perfect for two panels.
Note that OSX by default has some type of feature that reduces the realestate you have available.. don't ask me to explain it, i haven't really used it much.
Basically, with the Retina monitors, the resolution is actually too high for a lot of scenarios. You end up with tiny fonts, tiny icons, etc. So they somehow sample/zoom the sizes so that you get both really crisp renders but with very few real pixels on screen.
This may be what is causing you to be surprised that i am still having issues with a high resolution Retina screen. But, turning it off would be effectively the same thing as just turning my iTerm2 fontsize to ~8-10 or something tiny, allowing me to fit three panes.
Well I simply don't use the three way view. I find it easier to read when only having one window with the file having the <<< and >>> lines.
As an aside, I also use the fugitive plugin and the promiscuous one which makes the whole process easier.
Thanks for the ideas. While I agree with you that desktop IDE is a good place for design and architecture level reviews, having a lightweight web "IDE" will be beneficial as it does not require you to switch your local workspace to particular revisions for review.
Also I often find myself need to copy code from some old revisions, in that case, I just visit our web "IDE", find desired revisions with revision search helper, and open desired symbols to copy relevant code out.
A really good editor will allow you to do this without leaving. Pycharm/jetbrains handle this the best I have ever seen. Atom is almost there with a couple of the packages I have found
are the main ones, git-time-machine is probably my favorite package period in the Atom ecosystem. As it shows what is possible with completely user created UI.
I don't care much about code review, but it's a close enough attractor to the space of code reading that it seems to be draining attention. So let me hijack this topic and post a request for product (I'd write it myself, but priorities... adult life sucks hard).
--
I dream of a tool that facilitates code reading and exploration. It has some similar features with code review tools, namely:
- integration with version control systems
- basic semantic search/navigation
- looks clean
- not meant to be for writing code
But my dream tool also has following features I haven't seen implemented in any code review tool (or anywhere):
- annotations - not just "comments", but the ability to tag lines, to strike them out, highlight, color, scribble on them, etc. - basically anything you'd do with a printout of a code
- easy way to review history of a single file (with annotations)
- ability to easily bookmark areas / pieces of code and use those bookmarks in comments / annotations
- ability for viewing structural diagrams of the codebase
- full blown semantic search - who calls, calls who, etc.
- project-structure-oriented, not repository-history/commit-oriented
Basically, I'd love a tool not for collaboration, but for individual work - a tool that would facilitate exploring and familiarizing yourself with big codebases, as well as empower one when the time comes to do bigger refactorings.
Would be doubly useful if I could use it on a tablet, so that I could get up from in front of my computer to go and think about the changes I'm about to make (right now, I end up actually printing code if I have to refactor something very messy).
Sourcegraph CEO here. We 100% agree, and that's why we built Sourcegraph. Check out our roadmap at https://sourcegraph.com/plan.
And try browsing code on Sourcegraph: https://sourcegraph.com/github.com/gorilla/websocket/-/blob/... (we support other languages as well). Right-click on "parseURL" and choose "Find All References". If you click on "HasPrefix" a few lines below, you'll see a cross-repo jump (and the right-click menu lets you see global/cross-repo references).
Very interesting demo. So it has at least one feature I'm looking for :). Basically, I'd like something like that, but with annotations like in Acrobat Reader (but more), on a tablet, and off-line at least for my own codebase.
Shoot me an email at sqs@sourcegraph.com if you want to get early access to some of the upcoming things (or sign up at https://sourcegraph.com/beta). I think you'll like what's coming. Thanks for the bug report. :)
I've seen a couple brief comments about Upsource in this thread. Can anyone give a deeper dive on their experiences? I tried it very briefly but didn't have time to configure integration with my IDE, just played in the web browser. I suspect that means I didn't try the best feature.
Upsource team member here. Since Upsource indexes your code just like any JetBrains IDE does, it gives you code navigation, inspections, etc. in the browser, which means its "best features" don't require using it as an IDE plugin.
Pros: I'm obviously biased so I won't go into those.
Cons: it's not a lightweight tool that's happy with 1 gig of memory. Configuring and waiting for code indexes takes a bit of time, especially if you're trying it out on large legacy codebases. It also won't manage a Git repository for you.
Right now, I would take a button to go to the previous revision of a file, showing the full file with the diff underneath. That way I could very easily 'browse' through the history of a file to find out things like when a particular change got introduced or just get a feel for its history. Why on earth don't github/bitbucket provide this? Surely it's a reasonable and common requirement? Or is there something inherent to git that makes it too awkward?
Yes, that second video is pretty much exactly what I'm looking for. I've been considering implementing it myself as a general-purpose git tool (i.e. not github etc. dependant) - were there any major gotchas? Do you need to pre-cache commit or diff info. or is it efficient enough to do everything in real-time?
The major gotchas is building the indexing engine. Once you have that in place, getting the commit information takes milliseconds. The only time consuming thing is extracting the from and to blobs from the repo. However, that is a one time hit, since you can cache the blobs.
GitPlex can show history of any path (a file or directory) quickly via history button, and from there you can even refine the history (search for certain tags, commits made by certain people, etc) of the file, and once you get to the point, you can either view content of the file, or hit the compare button to compare with your previous browsed copy.
An example here:
http://gitplex.pmease.com/demo/android-framework-base/commit...
Some (if not most) GUI Git tools should do this, e.g. I personally use Git Extensions[1] which shows history and diff side-by-side.
For what it's worth, features like that (along with, say, line-by-line staging) are the reason why I usually use a GUI client and only drop down to the command line when necessary.
Are you looking for something akin to `git blame`? Github & Bitbucket both provide a gui for this.
Something even closer to what you're asking for... in github hit the 'history' button on a file (next to blame) and you'll get the commits which affected it. Hit the 7 character commit-id and you'll be taken to the diff of that change, jumped specifically to the file in question.
I never really use `git blame` - my primary git use case is as a single user.
The history button in github is close to what I'd like, but it's not quite as friendly as single next/previous buttons that just paginate the changes to a file. That makes cycling through the history very easy, whilst 'click commit id, back, remember which commit we just viewed, click following commit id, repeate' all sounds a bit painful.
I think GitPlex meets most of the requirement here if you are writing Java code (and more languages are being added). Unlike other tooks, it does not place any requirements on project build system (Maven, Gradle, etc) and can work on any project containing supported languages.
I'm building something like that now but instead of annotations in the code it captures your browse through the codebase as a tree that you can then annotate, save and share. It is going to run both in the browser to explore code hosted on GitHub, BitBucket, GitLab, etc and locally as an Electron app.
For quick browsing of a files commits I use Emacs with Magit and utilize the time travel feature of Git-Timemachine https://github.com/pidu/git-timemachine
You don't get the annotations you want, but you could make a comment with a common starting word like NOTE: then remove them before you merge the refactorings.
The trouble with that is, how on earth do you get the annotations to apply across revisions? Or would you be OK with them only applying to a given revision and then ... what, disappearing? Or going into a 'floating bucket' of annotations for the entire file?
I'd be fine with them sticking to particular lines of code[0] and disappearing if those lines were changed. This is not something I'd like to commit into codebase, it's for exploration / preparing work.
--
[0] - "smart stick" can be implemented by remembering not just the line in file, but also the contents of that line and a (fuzzy) context.
Interesting. In these terms, it could probably just be a totally separate, general-purpose 'text file annotation' tool with git support (but not a requirement).
Indeed. The closest I came to what I need was a proof-of-concept I did - printing source code to PDF and using Adobe Reader's annotation tools. Wasn't exactly convenient without a good ability to switch between multiple source files, but could be made to work. I'd love to have such browsing/annotation tool I could take with me to a park, to browse code and think about it while on a walk, without continuous distractions of the office / Internet connection.
After a fashion. A reading/exploration-oriented lightweight IDE. No IDE that I know of support scribbling over code, for example. Also, for the mode of work I'm thinking about, having no ability to actually write code would be a feature.
My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.
We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
You posted 10 of these comments and provoked users into emailing us to complain about spam. Those users are right, because HN isn't the place for this kind of thing, and certainly not repeatedly in multiple threads. We haven't banned your account because I'm sure you were acting in good faith, but please stop.
I'd be in favor of having some standard "code review markup language", which could contain review comments and workflows. Then you would be able to put these in files and make those files part of your repository (ie commit/push).
Then, you could build various frontends to handle these in a user friendly way if you like. But also, would be accessible and editable in your favorite text editor.
As long as the tools and processes don't get in the way of communication because they require comments to be written in a particular format or in a precise place. Too often, such tools end up in discouraging the very thing they're supposed to help.
This is something I've been thinking about quite a lot lately – I considered extending our git-flow a bit to contain review branches (or something comparable). If you'd like to chat a bit about potential solutions for your approach just drop me a line!
We solve this via gatekeeper rules (repository administrator defines rules such as who needs to review which part of code, or whose code needs to be reviewed (intern team for instance needs to be reviewed by core team etc), or what commit message rule should be followed etc.
This looks impressive, especially how they seem to handle rebases/squashes with force push, which is a problem that pretty much all other repo managers simply ignore (except for Gerrit, but that one has other problems...).
As I understand it, Phabricator largely avoids the problem because it is primarily patch-based and not branch-based? How would arcanist handle a force-pushed branch without simply starting a new review process?
Exactly, it sidesteps the problem by decoupling branches and code review. A review request is just like a diff in a mailbox. It'd just update the diff.
It's really close to the Linux kernel development model and it scales very well.
I checked Gerrit before and like its philosophy of enforcing atomic commits and linear history, but I do not like its way of adding special change id in commit message and push to refs/for/master. That makes new users confusing and makes it difficult to follow. So I build a gerrit gatekeeper in GitPlex to enforce same rule in pull request, that is: when you need to update a pull request, you must amend your previous commit followed by a force push. No special change-id or the magic refs/for/master will be necessary.
It's simply horrible to work with. It's a mystery to me how people actually review code through that cumbersome interface. Tracking a larger patch series is just painful, and I usually had to use other tools for doing the actual work. To me, Gerrit is not a tool for doing reviews, but more like a bureaucratic behemoth from project management where you have to click the right buttons and fill out the necessary forms, so that things somehow get merged. It's more like applying for a mortgage or doing taxes.
Gerrit's current web UI is awkward, but the backend service really has the fundamentals down, and it has a first-class REST API. I used that to create Gertty which is a console UI for Gerrit that makes reading and reviewing code (in a terminal!) easy and fast.
Very impressive. This has some features we've been missing in bitbucket/gitlab/github and it looks like the UI is well thought out and still simple.
The IDE-like source parsing is interesting, and I disagree with some of the other commenters here that that should only exist in an IDE, but the java limitation makes that just a novelty for us.
Particularly though the gerrit-style workflow and the rules engine for permissions is enticing. We'd love to move to something like gerrit but don't want to give up the friendliness of bitbucket/github.
Looks like a Java webapp running on top of jetty [1]. Interesting - that's a quick and easy deployment. I wonder what are the hosting requirements and performance implications.
Yes that is true. We build this tool with easy deployment in mind. And we've devoted a lot of our effort to performance. Just check the linux repository for instance (http://gitplex.pmease.com/demo/linux), GitPlex is able to calculate latest commits of many sub folders quickly, compared to decades needed by other tools, :)
If your repository is not as large as linux, a 1 cpu machine with 1G memory allocated to GitPlex will be more than enough.
We created GitPlex to manage our own code as result of not satisfying with existing tools on the market
"...not satisfying"? I think what you want to write here is something like this: "We created GitPlex to manage our own code as a result of dissatisfaction with existing tools on the market" or even better, a sentence shorter than that.
Well, in a sense, this departs from github in the sense that they try to keep everything as simple as possible (sort like the Apple design philosophy).
But developers are, or should be, power users. And in that regard a tool like this is VERY welcome. A tool that exposes some more sharp edges in exchange for flexibility.
We also try to keep things simple.
Without gatekeepers, the pull request workflow is quite the same as GitHub.
Advanced users can explore gatekeepers to achieve much flexible workflows.
Hackers may also write plugins to add their own gatekeepers in future releases. 8)
i've personally found using Reviewable[0] to be a delight, automatically plugs in your github workflow in that it modifies the comments in your original PR with comments left on reviewable itself. one killer feature is their batch comment mode, the ability to draft up a whole set of comments and publish in one go all the while tracking the resolution/conversation of each point brought up.
an example of this is here[1], batched comments with the multiple threads of discussions across various revisions and tracked to resolution.
We do that in backend with a hand written, simple parser just to pick up information we needed. And it is fast (can index all JDK8 source symbols in seconds).
i am currently working on a side project [1] to search for java-method usages and also parse java-code on the backend, but it's not as fast as i would like it to be. I did some very obvious performance improvement, but i suspect that for the most time i am waiting to download the sources/to complete the search request. There might also be some serious performance issues (it started as a hackathon project, so...). I hope to find time this weekend to do some benchmarking. I would guess you download the whole git repo at once and then do the parsing and not lazily per file? I also experience high memory usage, it might be the library that i am using.
Looks like many GitPlex downloads are going on... And this happens since two hours ago when I posted this news. The first time I've experienced with HN death hug, 8)
Another thing in my agenda now (to optimize the web site and download).
I've found, as the OP did, that the GitHub/Lab/Bucket code review UIs strongly encourage nitpicking over code style and strongly discourage true insightful reviews on a design and architecture level. This happens simply because of the amount of effort your have to do to see and feel the wider impact of a pull request on your codebase. It's like looking at code with blinders on.
So what you want to do is checkout the pull request and use your editor. We made this a habit here at TalkJS and the quality, speed and usefulness of our code reviews skyrocketed.
Actually we take it one step further: we dropped the commenting interface altogether. Our code reviews are commits, with code comments by a particular format:
My colleague Marcin can find all reviews intended for him by grepping for `REVIEW(marcin`. Git ensures that even across merges and code changes, comments stay put, and once Marcin applies the review comment he removes the comment. He can reply by adding a comment in the same format.The fact that review comments are right there in the git history also really helps track down complicated problems. Finally, we get the freedom of merging a PR anyway even though some things ought to be better, without losing track of the review comment. Obviously that's a code smell, but sometimes it's better to release first and refactor next day.
But even if you think this is insane and reviews don't belong in the code, I'd like to warmly encourage you to use your editor for reviews.