

A tiny tool to make using GitHub for code reviews a tiny bit easier - potomak
http://reviewth.is/

======
zrail
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>

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

~~~
tseabrooks
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".

------
Argorak
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... :/

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

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

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

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

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

------
alexchamberlain
Would it be more appropriate to use _git notes_?

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

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

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

------
asymmetric
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...](http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messages.html)

