This sounds like what they have in GitLab merge request flow: https://docs.gitlab.com/ee/user/project/merge_requests/versi...
Reorient GitHub pull requests around changesets
151–160 of 210 posts
Re: Reorient GitHub pull requests around changesets
#152Changesets 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…
Changesets in Gerrit are more easier to manage from processes and UX standpoint. There is no branch/commit/comment/rebase/commit/resolve-staled-comment/fight-for-true-pr-merging-strategy dance.
I'm doing a lot of review work and changesets are a killer feature not to lost in comments. Even for small-ish 50 line reviews.
Changesets especially powerful with local stack based development tools like stgit which allows to completely remove branch management.
Re: Reorient GitHub pull requests around changesets
#153I haven't used GitHub in a while but absolutely all of the author's issues are fixed in gitlab and I have a hard time believing GitHub is that far behind.
Re: Reorient GitHub pull requests around changesets
#154I don’t have experience with the outlined workflow, only with GitHub PR’s, but it feels like maybe the PR’s could too big if you have this problem? I’m anticipating some push back on this, because I didn’t notice it mentioned anywhere else, even though there are a fair number of comments. So, I may need take some time to understand these other tools. But, short of that, for me personally, keeping things small and rel…
You're absolutely right, the author's problem imply massive pull requests that I wouldn't accept in my workplace.
Re: Reorient GitHub pull requests around changesets
#155I don’t have experience with the outlined workflow, only with GitHub PR’s, but it feels like maybe the PR’s could too big if you have this problem? I’m anticipating some push back on this, because I didn’t notice it mentioned anywhere else, even though there are a fair number of comments. So, I may need take some time to understand these other tools. But, short of that, for me personally, keeping things small and rel…
Fracturing a big commit to smaller parts doesn't help. Amount of work is the same, number of comments would be higher or same due to bigger context loss. GH PR UI is notoriously confusing while reviewing multi commit PRs.
Re: Reorient GitHub pull requests around changesets
#156That approach works fine in gerrit. I always preferred it.
Re: Reorient GitHub pull requests around changesets
#157Earlier quoted context omitted.
I really don’t see the difference between force pushing and not when you are going to squash merge anyway.
Force pushes makes reviews hard to follow, especially if there are multiple rounds. GitLab handles it much better. Relatedly, does GitHub merge understand !squash and !fixup commands? I kind of gave up on those and just accepted a few trailing bugfix commits on PRs to not mess up peoples reviews (some projects also invalidate review on force push).
> some projects also invalidate review on force push
Those should also invalidate on a "normal" push if any changes are made. But yeah, it'd be nice to have the option to keep reviews valid on force-push if diff is identic and the only difference is rearranging commits/messages while still invalidating on any actual changes.
Re: Reorient GitHub pull requests around changesets
#158I've noticed listed problems, they surely do exist. but stepping back a little - proposed solution sounds like: "lets make a brand new version control system for already existing version control system".
Not really. There are many mature tools outside of the GitHub monoculture that do changesets, both on top of Git as well as other VCSs.
I don’t do much reviews these days but I remember the confusion of GitHub PRs. Things just disappear, especially with the rebase workflow which is preferable for improving reviewer burden.
I think Mitchell is mostly right here: a changeset is the most natural data structure for maintaining code. However, is it also the most natural construct for storing code in repositories, ie “should git be replaced in the long term?”. Can the merkle tree of blobs be replaced by an analogous merkle tree of changesets? That I don’t know. But it’s a worthwhile idea.
Re: Reorient GitHub pull requests around changesets
#159Earlier 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?
Maybe to go all-in on Blocks. https://blocks.githubnext.com
Re: Reorient GitHub pull requests around changesets
#160100% this. It is the biggest problem I have by far with GitHub. I really hope they can follow this advice and do something closer to Gerrit.