Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reorient GitHub pull requests around changesets

mitchellh.com

Post reply on HN
Print view View original

161–170 of 210 posts

Re: Reorient GitHub pull requests around changesets

#161

Post by 3np »

fahhem wrote: post #72

I truly believe that Reviewable is the best way to review code on GitHub, that's why I left a Head of Engineering post to come work here. Reviewable tracks code by revisions (aka changesets), not just the state of the git branch like GitHub, and many more improvements both to the broad strokes and to the small things. Want to immediately see which PR's you should review? Want to avoid getting pinged during the day to…

I just don't understand why it has to be remotely hosted (SaaS), as opposed to run locally. I hope this is reconsidered one day. I'm happy to pay with money, not with data, or having to rely on Reviewable for availability.

Re: Reorient GitHub pull requests around changesets

#163

Post by hahn-kev »

parentheses wrote: post #118

Changesets seem like a UX nightmare. While I understand the motivation, the complexity of version control today is mind boggling. We have a working copy, index, commits, branches, remotes, pull requests - all of these come into play when proposing even the simplest change to an open source repo today. The idea that adding yet another concept to the pile will make things better is something I can't agree with. Will it…

Don't forget forks lol

Re: Reorient GitHub pull requests around changesets

#164

Post by da39a3ee »

JohnKemeny wrote: post #139
da39a3ee wrote: post #133

Earlier quoted context omitted.

No, it is not a misconception. How do I apply a patch from gmail to a specific git repo on my computer? (I would genuinely like to know the answer, but it must not involve mutt, gnus, or dovecot!)

Copy the content of the email to your clipboard, type `git am` in your terminal, paste and C-d to complete.

OK thanks, that sounds fairly convenient for small patches. And I expect you'd say download the email for larger patches (as a sibling commenter suggests).

Re: Reorient GitHub pull requests around changesets

#165

Post by da39a3ee »

u801e wrote: post #148
da39a3ee wrote: post #133

Earlier quoted context omitted.

No, it is not a misconception. How do I apply a patch from gmail to a specific git repo on my computer? (I would genuinely like to know the answer, but it must not involve mutt, gnus, or dovecot!)

Save the email to your local machine (in gmail, click the 3 dots and choose download message). Then run git am

Right, thanks! (And using clipboard and stdin sounds even more convenient for small patches as a sibling comment suggests.)

Re: Reorient GitHub pull requests around changesets

#166

Post by hahn-kev »

jayroh wrote: post #53
codeapprove wrote: post #19

I agree 1000%. I’m the creator of what I believe is a better review interface for GitHub ( https://codeapprove.com ) but there are also many others: * CodeApprove (codeapprove.com) * Graphite (graphite.dev) * Reviewable (reviewable.io) * Axolo (axolo.co) * Viezly (viezly.com) * Mergeboard (mergeboard.com) * Codestream (codestream.com) * Pullpo (pullpo.io) * ReviewPad (reviewpad.com) * Planar (useplanar.com) * Visibly…

Question: does CodeApprove place related files in closer proximity during review? I would _love_ to have a class and its test next to each other instead of sorted alphabetically. I'm tired of jumping around all over the place, trying to traverse through my review thought process.

I feel like if you want that then you should colocate the files in the same folder.

Re: Reorient GitHub pull requests around changesets

#167

Post by ninkendo »

Waterluvian wrote: post #20
ninkendo wrote: post #18

Earlier quoted context omitted.

GitHub seems to have no interest whatsoever in making the process of reviewing code any better or easier. It’s still essentially the same as it was 15 years ago. They introduced batched review comments well over five years ago, and still haven’t fixed the obvious issues with it, like how if you’re the PR author and you’re replying to someone else’s comment, and hit Cmd+Enter, it starts a review of your own PR (requir…

I review my own PRs regularly. It’s how I talk through all my changes with meaningful inline comment threads. I prefer the behaviour you’re commenting about because I want to do those things in a “review” rather than pollute inboxes with one-off comments. I think the main issue is that everyone has their happy paths through review, but those aren’t everyone’s happy paths. It’s why I like that having a variety of tool…

I’m talking about replies to other people’s comments. If someone asks you a question in a review, it seems crazy to me that you should submit your own review of your own code, complete with an approval (huh?) just to answer it.

If you’re saying it’s better to batch together multiple replies to multiple people’s comments at once, fine, but that’s not a “review”. Why should you have to “approve” your own code (what does that even mean?) to do this?

Re: Reorient GitHub pull requests around changesets

#168

Post by janosdebugs »

TazeTSchnitzel wrote: post #142

The changeset workflow is what Gerrit uses. Gerrit is great. There's a free service (GerritHub) that lets you use Gerrit for your public GitHub project. The learning curve for it is pretty steep if you've never used Gerrit before, though, and it does have some reliability issues. But for a certain kind of project it can really transform the code review experience.

Reviewing code on GitHub is tough, especially with larger changes. However, Gerrit's user interface is so beginner/user hostile that I would still prefer it to Gerrit. It scares away new contributors. :(

Re: Reorient GitHub pull requests around changesets

#170

Post by mmcnl »

parentheses wrote: post #118

Changesets seem like a UX nightmare. While I understand the motivation, the complexity of version control today is mind boggling. We have a working copy, index, commits, branches, remotes, pull requests - all of these come into play when proposing even the simplest change to an open source repo today. The idea that adding yet another concept to the pile will make things better is something I can't agree with. Will it…

I completely agree.
Post reply on HN