IIUC, he's referring to a workflow that Gerrit implements 1-to-1, isn't he?
It's the email flow that's existed before gerrit and phabricator. Both of which implemented because it makes sense. Then github came along and here we are.
Reorient GitHub pull requests around changesets
21–30 of 210 posts
Re: Reorient GitHub pull requests around changesets
#22More and more I'm starting to appreciate the email based PR
Re: Reorient GitHub pull requests around changesets
#23I 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.
Oh man yes I dislike non-squash merges very much because they make it so hard to go from the Git blame to the pull request discussion
Re: Reorient GitHub pull requests around changesets
#24I 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…
"I think in the end we should not expect GitHub to provide the best option here. We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option. Everyone should be shopping for code review tools!
"
I understand this linke of thinking might suit you but I fear it is not as convincing as it sounds to you. At least it's not to me.
Re: Reorient GitHub pull requests around changesets
#25I 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.
I really don’t see the difference between force pushing and not when you are going to squash merge anyway.
Re: Reorient GitHub pull requests around changesets
#26I am slowly convinced that comments on PRs are like comments on blog posts or youtube videos. Ephemeral, irrelevant and ineffective. If you really want to "reply", put up your own blog post or a "reacts" video. Same for code. unless it's simple typo fixes or improvements, deeper fixes come from writing code samples yourself.
I recently commented on a juniors code, and put in about four lines of code showing how I would improve the performance- but to do so I of course had to bring up a REPL and put the code in and run it and had more or less done a PR.
Make it faster and easier to inject and piece of code into the PR flow (branch pu?), make the whole code base simple to run from any point in memory, fully testrigged, so "just those highlighted lines" can be run and everyone can see.
What we are doing with this OP approach is making it easier for a human brain to imagine what the runtime will be like. That's the wrong approach - make it easier to have the runtime run over the chnaged lines of code and let people step through at PR time, and then make their changes alongside.
Or just leave a comment.
But we know what the rules are on comments on the internet
Re: Reorient GitHub pull requests around changesets
#27I 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.
[deleted]
Re: Reorient GitHub pull requests around changesets
#28Hmm, not saying Github is perfect, but I think there’s value in providing the simplest possible experience as the default.
Re: Reorient GitHub pull requests around changesets
#29I 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…
"I think in the end we should not expect GitHub to provide the best option here. We should expect them to provide a basic option (which they do) and for sophisticated consumers to pay more for a much better option. Everyone should be shopping for code review tools! " I understand this linke of thinking might suit you but I fear it is not as convincing as it sounds to you. At least it's not to me.
Here's how I like to think about it: GitHub is a generalist. They have a big platform with lots of features besides code review, so even though they also have lots of employees they won't be able to focus on code review as much as a dedicated company could. They also have a huge number of users to please so they can't afford to rock the boat too much or make the learning curve too steep.
I think therefore it's pretty much inevitable that if you need a more advanced code review tool you'll end up picking a third party one. Though admittedly, as the founder of Reviewable, that thinking does rather suit me too. ("It is difficult to get a man to understand something when his salary depends on his not understanding it" and all that. :D )
Re: Reorient GitHub pull requests around changesets
#30Generally, 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 & consistently across apps. PRs would just be one example of something that would be better tracked.