Live data from Hacker News

Reorient GitHub pull requests around changesets

mitchellh.com

171–180 of 210 posts

Re: Reorient GitHub pull requests around changesets

#171

I agree. As a way to minimise the pain on GitHub today, we disallow force pushing and enforce squash merging. Force pushing is a nightmarish behaviour, once a Pull Request is opened the branch must be append only.

That's a better solution than changing the Git(Hub) model. If this works for you, then why the need to change anything?

Re: Reorient GitHub pull requests around changesets

#172
post #127

Github had this planned in their old roadmap... But then they deleted it... https://web.archive.org/web/20220831234107/https://github.co...

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…

> Instead, they are midway through porting Rails views to use React, keeping most pages looking identical while introducing bugs and regressing previous usability improvements on a weekly basis. A real shame

I predicted this the moment I saw the React dev tools icon going blue when browsing GitHub. My comment (which I can’t find right now, I’m on my phone) was along the lines of them going the “Reddit way”. A totally worse experience for the end user just for the happiness of the React fanboys working there.

I already can’t stand the code browsing UI, which randomly closes or open a sidebar as you navigate back, or the search input which doesn’t even look good to me. What a total shame they’re messing it up so badly. GitHub had one of the best UIs in my opinion, and they’re just messing it up for the sake of keeping some devs happy.

Re: Reorient GitHub pull requests around changesets

#173
post #138

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…

Wow, why would they spend so much energy rewriting Rails code into React?

Fashion and trends followed by new hires, most likely.

Re: Reorient GitHub pull requests around changesets

#174
post #110

Earlier quoted context omitted.

I like this approach too, but almost no one understands it (i.e. the idea it's possible is foreign) and UI support for it is non-existent in all the major products. It would be wonderful if we could ditch "change these lines" type comments in favour of just letting merge requests with the changes be easily surfaced.

I might be wrong but it sounds like you don't know about the GitHub PR feature where you select the lines, and GitHub allows you to edit them, and posts a diff when you're done, and if the author accepts it out becomes a jointly authored commit.

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 changes. The point was to ensure that you could easily expand the MR beyond the diff of changed lines, which was frequently inadequate to review a patch properly since it omitted context.

Re: Reorient GitHub pull requests around changesets

#175
post #138

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…

Wow, why would they spend so much energy rewriting Rails code into React?

Someone likely saw it as a good chance to "take over" more of the tech team headcount.

Re: Reorient GitHub pull requests around changesets

#176

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 agree as I used a tool Reviewable which is accurate about which version of the change is being commented on, which files you reviewed etc. It even supported rebases. And no comment was finally marked resolved until the original author marked it as such.

It was great for skilled users to navigate with the keyboard and easy to see when everything was resolved. But if used as intended, like fixing some commented chunks while debating others, the information displayed became unwieldy. GitHub PR reviews are simpler and that isn't a bad thing.

Edit: looks like it's still available and hasn't changed massively, I'm not surprised as probably a lot of licensees cancelled when GitHub added reviews (my company did). Check it out if the article speaks to you.

Re: Reorient GitHub pull requests around changesets

#177
post #2

Surprised he didn't refer to stack PR based systems like Gerrit for reference. I have never tried those apps that build a top GitHub. I remember Facebook's sapling has a web client as well that does stack reviews.

There are two mentions of Gerrit in the article. Granted neither goes into detail, but both reference it as prior art on the topic.

Oops. I must have missed the mentions.

Re: Reorient GitHub pull requests around changesets

#178
post #53

Earlier quoted context omitted.

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.

Convention and culture. Hence - I wish that I could.

Re: Reorient GitHub pull requests around changesets

#179

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 agree as I used a tool Reviewable which is accurate about which version of the change is being commented on, which files you reviewed etc. It even supported rebases. And no comment was finally marked resolved until the original author marked it as such. It was great for skilled users to navigate with the keyboard and easy to see when everything was resolved. But if used as intended, like fixing some commented chunk…

We're still around and we've actually changed a lot. Our homepage is untouched (for now!) but you can check out our blog for proof of life :D

http://blog.reviewable.io/

Re: Reorient GitHub pull requests around changesets

#180
post #161
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.

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.
Post reply on HN