A tiny tool to make using GitHub for code reviews a tiny bit easier | Hacker News Reader

A tiny tool to make using GitHub for code reviews a tiny bit easier

reviewth.is

57 pointspotomak15 comments

This is interesting but GitHub already has a fine code review system. A coworker put together a script named pullme[1] that automates GitHub's push-to-topic-branch-and-issue-pull-request workflow. I've been using it for a week or two and it has made my workflow so much better.

[1]: https://github.com/AndrewLorente/Pullme

Nice idea, but GitHub already has pull requests which work wonderfully for code reviews.

When I'm finished working on my branch I can submit a pull request. Everyone else on the team gets an email and can take a look at the new changes. We can have a conversation about the code and people can pull the branch and make their own changes. It's all very seamless and works great for remote teams.

This highlights my only real complaint with github (Started out using Fogbugz / kiln [Hg])... Why does EVERYONE need to be notified?

This is counterproductive. We have 15 engineers and we all work on different submodules. When I issue a pull request (Or create a new issue) I would like to be able to select a subset of people to ping about it instead of announcing it to everyone. the current situation just creates a pile of messages 90% of which you don't care about so you have to filter them to find the ones that are relevant to you.

Along the same line I think it'd be nice to send something to a particular person that says, "Hey, YOU must review this and approve the pull request".

I like the idea, but I would really prefer not having to mess with my commit messages for every other system. Its okay for issue trackers (because the commit is definitely referring to an issue/task now and in the future), but it gets really messy once you use the issue text as a notifier.

We usually ask for review using comments and by addressing users directly, but AFAIK, github does not allow you to hook into that... :/

It should do with the event API: http://developer.github.com/v3/events/types/ (IssueCommentEvent and/or CommitComment)

For GitHub usernames you don't need that, but I could see that being useful for email addresses.

Thank you. I skimmed the documentation, but I only found the event timelines. I didn't know that the v3 API had such fine-grained control for hooks.

For the record: this was made before GitHub pull requests worked with the same repo, and before the event API. It hasn't really been touched since.

I do agree that it's not ideal for the review request to be enshrined in commit history. We've not used this for some for that reason.

does code review need to be tied to your scm? i can see how it means slightly less work, but what's the minimum infrastructure you need to make it independent of the scm? i would guess it's little more than some bash and procmail scripts (assuming unix).

The kernel model (git format-patch, git send-email, git am --signoff) might be automated a little bit more with procmail scripts that auto-apply patches sent to a mailing list once they've been acked as needing no further revision. That workflow has the benefit of decentralisation, but I don't think other SCMs have the equivalent commands. Widespread support is particularly necessary for the people who initiate reviews, since they are more numerous and less likely to have specific tools installed.

It doesn't have to be, but integrating with GitHub's line- and commit-level comments and pull requests certainly helps incorporate code reviews into the history of the project and each file in it.

Would it be more appropriate to use git notes?

We use pull requests to review code before it gets merged into master, works really nicely.

On the same topic, here's a chrome extension to make comment boxes have a monospace font:

https://github.com/jdz/github-font-fix

It helps a lot when typing code and markdown syntax in the comment boxes.

Nice work, looks useful - if my employers used git that is, sadly I'm stuck on svn (for work)

nice, but the example on the homepage doesn't follow the git commit message guidelines[1].

it would be nice if you could fix that, so as to not spread bad practices any more than they already are.

[1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...

Reply on news.ycombinator.com