This looks super interesting, it looks like it'd solve a few of my gripes with GitHub reviews. Congratulations on the launch! One thing I've always wondered is why all these review tools use centralised databases. Git itself is a distributed model and reviews tend to boil down to code comments on set of lines or characters. I'm always surprised no one has created a review tool that ships around reviews like patch fil…
Show HN: Crocodile - Better code review for GitHub
41–50 of 62 posts
Re: Show HN: Crocodile - Better code review for GitHub
#42For any PR that is nontrivial I will pull it locally so that I can more easily navigate to functions/data types that are used by or changed in the PR. It would be nice if the review ui provided a way to click through to the definition of a symbol that appears in the code. (I think gh does this when browsing code for some languages.)
A related helpful feature would be the ability to see “what calls this”. Currently I have to do this kind of review with ‘git grep’, after pulling locally.
I’d also love to be able to toggle into ‘git blame’ for a given bit of code, in order to better understand why the code is in its current state
Re: Show HN: Crocodile - Better code review for GitHub
#43Not a knock against crocodile, which looks like a nice set of improvements over gh, but something I’d like to see done better in any code review system is significantly better code navigation. For any PR that is nontrivial I will pull it locally so that I can more easily navigate to functions/data types that are used by or changed in the PR. It would be nice if the review ui provided a way to click through to the def…
Re: Show HN: Crocodile - Better code review for GitHub
#44Not a knock against crocodile, which looks like a nice set of improvements over gh, but something I’d like to see done better in any code review system is significantly better code navigation. For any PR that is nontrivial I will pull it locally so that I can more easily navigate to functions/data types that are used by or changed in the PR. It would be nice if the review ui provided a way to click through to the def…
You're basically asking for an IDE to be part of your code review tool, which I don't think is a bad idea
Re: Show HN: Crocodile - Better code review for GitHub
#45This looks super interesting, it looks like it'd solve a few of my gripes with GitHub reviews. Congratulations on the launch! One thing I've always wondered is why all these review tools use centralised databases. Git itself is a distributed model and reviews tend to boil down to code comments on set of lines or characters. I'm always surprised no one has created a review tool that ships around reviews like patch fil…
Well there is git-appraise[1] used by Google which stores it's data in the git repo itself. [1]: https://github.com/google/git-appraise
Re: Show HN: Crocodile - Better code review for GitHub
#46Not a knock against crocodile, which looks like a nice set of improvements over gh, but something I’d like to see done better in any code review system is significantly better code navigation. For any PR that is nontrivial I will pull it locally so that I can more easily navigate to functions/data types that are used by or changed in the PR. It would be nice if the review ui provided a way to click through to the def…
You're basically asking for an IDE to be part of your code review tool, which I don't think is a bad idea
Re: Show HN: Crocodile - Better code review for GitHub
#47Re: Show HN: Crocodile - Better code review for GitHub
#48Re: Show HN: Crocodile - Better code review for GitHub
#49Not a knock against crocodile, which looks like a nice set of improvements over gh, but something I’d like to see done better in any code review system is significantly better code navigation. For any PR that is nontrivial I will pull it locally so that I can more easily navigate to functions/data types that are used by or changed in the PR. It would be nice if the review ui provided a way to click through to the def…
Re: Show HN: Crocodile - Better code review for GitHub
#50This is cool! I'm happy to see more options in this space. The best code review tool I've ever used was a tool at Google called Critique.[0] They've open-sourced it as Gerrit[1], but there are sadly no hosted versions available for under $15k/yr, and it's complicated to self-host. I've been using Reviewable, and my experience has been good not great. Github's native code review has caught up a bit, but Github's revie…
> Steep learning curve
Guilty as charged. I think it's cohesive and efficient once you learn it but the learning curve is quite steep. We keep trying to think of ways to flatten it a bit but haven't had any great ideas so far. If you have thoughts on this -- or could point us to a great UX designer with dev tools experience -- it would be much appreciated!
> Performance
There are some obvious things we're working towards to improve it but these days most reviews load in 3-4 seconds for me, even on a not-very-awesome laptop. What kind of platform are you seeing 10 second load times on, and how's your Internet latency to us-central? Please open an issue and we can work through it together.
> Complicated configuration
Yeah, there's a lot of support for legacy and highly customized workflows in there. But these days the primary and default integration is with GitHub's approve/request changes workflow, which gives you one-click approve -- have you tried using that? (Efficient multi-repo config updates are also on the todo list, but never quite rose to the top.)
> Excessive permissions
This is an unavoidable side-effect of using GitHub's OAuth authorization mechanism. GitHub Apps allow finer-grained permissions but they didn't exist when we created Reviewable and don't have a good answer for listing PRs, which would make our dashboard significantly less useful. We do have a transition planned out but at this point our main customers are enterprise folks who run their own GHE Server and don't much care about fine-grained permissions, so the ROI doesn't pencil out.
> Thread state is unclear
Huh, I'm surprised by this one. The basic flow is: 1. Reviewer creates a discussion (disposition defaults to Blocking). 2. Author responds with questions/comments (disposition defaults to Discussing). 3. Reviewer clarifies (disposition unchanged) or clicks the big Resolve button (disposition changes to Satisfied, discussion is resolved). 4. Author addresses the comment and clicks the big Done button (disposition changes to Satisfied). 5. Reviewer checks and, if satisfied, clicks Resolve (disposition changes to Satisfied and discussion is resolved).
Basically, at every step you either reply to keep the discussion going, or click the button to indicate that you're fine with closing it out. You shouldn't even need to care about the specific disposition unless you're trying to run more advanced workflows.
> No development
Yeah, I pretty much abandoned the blog and should probably take it down. However, we do ship new features regularly and post updates on Headway [1]. These should also pop up as the "red circle new stuff counter" in the UI, but perhaps your browser is blocking that third-party connection. (Headway only gets major feature posts, but there's a lot more work going on in the background that's only reported on the enterprise changelog [2].) I'm not a fan of spammy email newsletters so we don't send those.
Again, thanks for the feedback, and don't be a stranger -- it's easy to reach us through email, chat, issues, etc., and we respond promptly to every message. Even if we have to hunt them down on HN. :)
[1] https://headwayapp.co/reviewable-changelog [2] https://github.com/Reviewable/Reviewable/blob/master/enterpr...