Live data from Hacker News

Show HN: Crocodile - Better code review for GitHub

crocodile.dev

41–50 of 62 posts

Re: Show HN: Crocodile - Better code review for GitHub

#41

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…

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

#42
Not 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 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

#43

Not 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

#44

Not 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

ctags allows this and isn’t necessarily part of an IDE. Granted, that may be where most people encounter this feature.

Re: Show HN: Crocodile - Better code review for GitHub

#45
post #41

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…

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

Oh wow I totally hadn't come across this one, thanks

Re: Show HN: Crocodile - Better code review for GitHub

#46

Not 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

Yeah, IDEA already basically supports this concept: https://blog.jetbrains.com/idea/2018/10/intellij-idea-2018-3...

Re: Show HN: Crocodile - Better code review for GitHub

#49

Not 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…

Hitting the keyboard shortcut "." on a PR in GitHub to open it in a vs code web view is pretty great, and I find it a substantial improvement to the normal GitHub PR workflow, especially with large PRs. You can also install the GitHub PR extension in vs code to get the same experience locally, along with gitlens to get a nice inline blame.

Re: Show HN: Crocodile - Better code review for GitHub

#50
post #18

This 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…

Hey, thanks for the feedback on Reviewable! You make some really good points:

> 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...

Post reply on HN