logoalt Hacker News

jenadineyesterday at 9:21 PM9 repliesview on HN

I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit:

- merge some commits independently when partial work is ready.

- mark some commit as reviewed.

- UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is familiar with that)

- ability to attach a comment to a specific commit, or to the commit message.

- better way to visualize what change over time in each forced push/revision (diff of diff)

Git itself already has the concept of commit. Why put this "stacked PR" abstraction on top of it?

Or is there a difference I don't see?


Replies

tcoff91yesterday at 9:28 PM

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub.

The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently.

It's really useful in larger corporate environments.

I've used stacked PRs when doing things like upgrading react-native in a monorepo. It required a massive amount of changes, and would be really hard to review as a single pull request. It has to be landed all at once, it's all or nothing. But being able to review it as smaller independent PRs is helpful.

Stacking PRs is also useful even when you don't need to merge the entire stack at once.

show 4 replies
mikeocoolyesterday at 10:01 PM

Constantly rewriting git history with squashes, rebases, manual changes, and force pushes has always seemed like leaving a loaded gun pointed at your foot to me.

Especially since you get all of the same advantages with plain old stream on consciousness commits and merges using:

git merge --no-ff

git log --first-parent

git bisect --first-parent

show 3 replies
d0mineyesterday at 10:15 PM

You are describing gerrit.

https://www.gerritcodereview.com/

xixixaoyesterday at 9:34 PM

Workflows can vary, but what I like:

PR/MR is an "atomic" change (ideally the smallest change that can be landed separately - smallest makes it easier to review, bisect and revert)

Individual commits (or what "versions" are in Phabricator) are used for the evolution of the PR/MR to achieve that change.

But really I have 2 use cases for the commits:

1. the PR/MR is still too big, so I split it into individual commits (I know they will land together)

2. I keep the history of the evolution of the PR/MR in the commits ("changed foo to bar cause its a better approach")

ahmadyantoday at 12:36 AM

the best implementation i've worked with was SuperSmartLog (SSL) at Meta, which was open-sourced at interactive smartlog (https://sapling-scm.com/docs/addons/isl/). There are also extension for it in VSCode, etc.

Surprisingly it never gained the adoption it deserved.

icytoday at 4:51 AM

We’ve got this over on Tangled. :) https://tangled.org

rtpgtoday at 6:21 AM

yeah interdiffing and being able to cherrypick in a review just there and getting it done is nice.

Perhaps a future iteration of this feature will at least allow us to do something like merge just steps of it if they can be reordered.

trashburgertoday at 10:43 AM

You want something like Gerrit.

LuttelBurchtjetoday at 8:56 AM

[dead]