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

191–200 of 210 posts

Re: Reorient GitHub pull requests around changesets

#191

Post by halostatue »

ninkendo wrote: post #18
bhouston wrote: post #14

This is a great suggestion and likely not that hard for GitHub to implement. I am surprised this isn’t updated more than it is.

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…

If you reply to someone else's comment from the discussion tab, it does not start a review of your own PR. In the code tab, I have seen an option to start a review or just make a one off comment. I generally prefer to make them as a review, because I am typically replying to comments in a batch.

Re: Reorient GitHub pull requests around changesets

#192

Post by halostatue »

epolanski wrote: post #62

Jm2c, but by far the best place I've ever worked (my current client) we don't do code reviews at all unless the author wants feedback. PRs are good ways to defend your code base from bad code, and they were born in open source where you literally have no clue who the contributor is, but years of experience left me convinced that I don't want such a system where there's constant need to overview each other's work. I w…

I have been in the industry for a fairly long time and I have seen code review tools pop up, and GitHub came fairly late to the table (IIRC, I was using a code review tool in 2007 against Perforce; GitHub wasn’t generally available until 2008 and I think I joined in late 2008 or early 2009).

I have been on teams where we simply merged things when complete and where we required code review before merge. In every case, the latter had better overall speed because we weren’t (usually) introducing regressions because no one had seen the code. (Pairing is a form of real-time code review, but the team I worked on that used pairing heavily still needed code review; I remember a regression was introduced even though the code had been pair-developed.)

There is, however, a case where if one works in an industry where ISO270001 or SOC2 or PCI compliance is required, recommended, whatever — you will have to have a policy on code review in order to pass.

Re: Reorient GitHub pull requests around changesets

#193

Post by XorNot »

da39a3ee wrote: post #189
XorNot wrote: post #174

Earlier quoted context omitted.

In situations where I'm doing PR reviews seriously in a multi-developer environment I'm usually on Gitlab. Gitlab definitely has some features for this sort of thing, but I've never been able to use them seamlessly or quickly. I was at one point considering writing a tool which would checkout an MR, then let you just edit it as per normal, and then would submit the whole thing back to a Gitlab MR as a set of proposed…

One way to do that is to open a second PR which targets the branch of the first PR. I think that's also probably the most natural way -- would you agree? I don't see it done much, but I've done it once or twice and I'd embrace it if it were more culturally standard.

That's what the parent comment is talking about though: and I agree it's better, but it just pops as another global PR.

The UI doesn't know what to do with it, and most developers don't really understand it without spending a bunch of time explaining it.

When it works, it works great but the overhead is ridiculous since you get nothing inline on the UI: ideally something like the commits should pop up as comments, with accept/reject/discuss options.

Re: Reorient GitHub pull requests around changesets

#194

Post by u801e »

da39a3ee wrote: post #165
u801e wrote: post #148

Earlier quoted context omitted.

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

Copy-paste may not work depending on how the email client renders the email. For example, if the email client doesn't preserve prefixed whitespace, then the resulting patch may be corrupted or not apply. Saving the actual email to a file on disk would avoid that issue.

Re: Reorient GitHub pull requests around changesets

#195

Post by earthboundkid »

Noumenon72 wrote: post #126
earthboundkid wrote: post #32

Earlier quoted context omitted.

I’ve said for a while that the problem with Git’s data model is that the branch information is not itself versioned. I want Git but for Git.

Git reflog provides history and rollback, what else do you need?

Oh boy an ephemeral log that doesn’t sync.

Re: Reorient GitHub pull requests around changesets

#196

Post by 3np »

fahhem wrote: post #180
3np wrote: post #161

Earlier quoted context omitted.

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.

We have an on-prem edition that doesn't even phone home, so you don't have to rely on us for anything but updates.

What's the pricing like for individuals and what payment options are you open for? I just saw "Enterprise - contact us" and assuming you were not interested in private individuals for this.

Re: Reorient GitHub pull requests around changesets

#197

Post by mhh__ »

ravenstine wrote: post #76
mhh__ wrote: post #58

Earlier quoted context omitted.

That's like saying it's OK to expect (say) Ford to make a car with no steering wheel. GitHub basically define the baseline for the entire industry and have millions upon millions to blow on trying to do better. (OK, Saab did actually do that once but they're weird)

The two aren't even remotely comparable. Whose compny went out of control and crashed because of GitHub missing a feature with their code review?

The tail is not as painful as real engineering but as an industry we throw away billions in value every year to dumb processes. There is more to this than just the scar tissue.

It's not just a feature, the model is fundamentally different and much more conducive to delivery, feedback, and happiness.

Re: Reorient GitHub pull requests around changesets

#198

Post by da39a3ee »

XorNot wrote: post #193
da39a3ee wrote: post #189

Earlier quoted context omitted.

One way to do that is to open a second PR which targets the branch of the first PR. I think that's also probably the most natural way -- would you agree? I don't see it done much, but I've done it once or twice and I'd embrace it if it were more culturally standard.

That's what the parent comment is talking about though: and I agree it's better, but it just pops as another global PR. The UI doesn't know what to do with it, and most developers don't really understand it without spending a bunch of time explaining it. When it works, it works great but the overhead is ridiculous since you get nothing inline on the UI: ideally something like the commits should pop up as comments, wi…

Right, agree with all that.

Re: Reorient GitHub pull requests around changesets

#199

Post by fahhem »

jen20 wrote: post #185
mikemcquaid wrote: post #136

Earlier quoted context omitted.

I left GitHub earlier this year after a decade. I’ve seen mockups, hack week projects and proof of concepts of this for the last 5 years (at least). A lot of engineers there knew this is the future that PRs need but GitHub at this point seems organisationally incapable of delivering these sorts of large improvements (Microsoft is perhaps partly but definitely not wholly to blame for this). Instead, they are midway th…

This would explain something else too, probably: a few years ago I did a call with some GH folks talking about the idea of making the commit message applied to a squash merge part of the review itself. Apparently this was very common feedback and I know that at least five other people who were maintaining large scale open source at the time gave it that week too. It’s never gone anywhere though, and as a result I hav…

This is a feature of Reviewable.io, there's a system file called Commits where you can comment on the commit titles and descriptions!

Re: Reorient GitHub pull requests around changesets

#200

Post by fahhem »

3np wrote: post #196
fahhem wrote: post #180

Earlier quoted context omitted.

We have an on-prem edition that doesn't even phone home, so you don't have to rely on us for anything but updates.

What's the pricing like for individuals and what payment options are you open for? I just saw "Enterprise - contact us" and assuming you were not interested in private individuals for this.

I'd be happy to chat, though we'd likely come up with something unique to individuals so we're not wasting each other's time every year. Reach out to support@reviewable.io and mention this thread
Post reply on HN