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

61–70 of 210 posts

Re: Reorient GitHub pull requests around changesets

#61

Post by fhcuvuvuc »

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.

[dead]

Re: Reorient GitHub pull requests around changesets

#62

Post by epolanski »

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 want to work with a team where there is high respect and trust. A team where I know I won't like or love all the decisions others make, but I trust their judgement. Maybe they did indeed hack an ugly solution cheating the type system and automated controls. So what? What matters is if they have done so for good reasons (stuff was super urgent, a proper solution was just not worth the effort as the feature/fix was really not important for the business).

This made development speed skyrocket and I'm no longer bound to infinite code reviews as if we were sending rockets on Mars.

I also want to say, code quality is high, but this stems both from working with great individuals that can be trusted and from much higher interaction speed.

Re: Reorient GitHub pull requests around changesets

#63

Post by jacobegold »

earthboundkid wrote: post #32
jauntywundrkind wrote: post #30

Generally, it feels like a bit of a farce that source code is very well well version controlled, but nothing else is. Data isn't well managed. Isn't version controlled well. The pull request is just another type of data. We can keep improving each applications model. But some day, imo, the general project of computing needs to take data more seriously & develop general tools for managing data over time well & consist…

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.

This is what Facebook did extremely well with Phabricator, which was then open sourced.

Re: Reorient GitHub pull requests around changesets

#64

Post by eddythompson80 »

mbakke wrote: post #59
eddythompson80 wrote: post #55

Earlier quoted context omitted.

I don’t think there is a one size fits all answer here. “Oops” commits make blame useless too plus they make following any meaningful change very hard. You want small commits in main, so send small PRs. If you have a feature, you can do a feature branch and merge into it the small commits then merge (don’t squash) feature branch into main.

I see now that the grandparent was enforcing squash commits, did not mean to single out your comment. It just blows my mind as someone with a somewhat perfectionist approach to rebasing (to the extent I sometimes intentionally break up or reorder commits to make the changes more intentional or natural, even when it causes nasty local merge conflicts) :P

Well, I’d appreciate it if I collaborate on a repo with you. I end up giving up commit hygiene due to the absolute lack of interest from folks I work with unfortunately :)

Re: Reorient GitHub pull requests around changesets

#65

Post by fahhem »

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 can't speak for CodeApprove, but Reviewable has file grouping capabilities so users can groups files based on anything they want (using a javascript function to do it)

Re: Reorient GitHub pull requests around changesets

#66

Post by jacobegold »

kemayo wrote: post #40

I work with Gerrit in my job, and find a stack of patches to be a useful way to deal with things... but I've also seen that it definitely has a learning curve for people who're not used to it. There's something to be said for the GitHub pull-request "just smush together all the commits on this branch" model in terms of ease of understanding. It's possible that better tooling would help there, of course. (A surprising…

Better tooling is definitely the answer here -- I used to work at Facebook where rebasing dependent patches in Mercurial when you needed to adjust something felt like a first-classed flow, and I'm currently working on a tool that does the same thing, but on top of Git and GitHub.

Re: Reorient GitHub pull requests around changesets

#67

Post by neo2006 »

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 don't see code review as an overwatch but a good communication tool and a way to think about problems collectively. Code review reduce bugs because it permit to have people think about the problem from multiple angles. About decisions, I think important design decisions need to be taken prior to the code review steps ,and also reviewed. I'm not sure what context you worked in that gave you that opinion about code review being a sign of distrust and I think the problem lay within the culture in those places not the code review practice it self.

Re: Reorient GitHub pull requests around changesets

#68

Post by jacobegold »

epolanski wrote: post #57
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…

Average org already pays so many saas and I have to pay one for code reviews too when I'm already paying GitHub? Also, there isn't only paying customers having this issue but large OS too.

Large OSS feels like a different use case than the big company one, to be honest -- I think that what maintainers care about is vastly different than what companies do. GitHub feels optimized for the former (OSS) as it is today.

Re: Reorient GitHub pull requests around changesets

#70

Post by jacobegold »

setheron wrote: 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.

I used to work at FB, and unfortunately the Sapling review client that shows GH PRs has nothing on the the actual internal code review tooling at Facebook (now called Diffs, formerly Phabricator). I miss that tool so much
Post reply on HN