> I also heard friends rave about "stacked diffs" but struggled to understand what exactly was going on there. Nothing I read or conversations I had have clicked.
I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.
For me, my git brain is very low level. And none of them ever explains what actually happens under the hood, or how that was different than branching…
With some respect, I think “rebase centric workflow” doesn’t really cover it: I use rebasing heavily with GitHub. A “trunk based development where all branches are rebased before merge so there’s never merge commits, please add to commits and rebase the branches in response to review comments” development style is still very rebase centric, but not stacked.
You also have to remember (though there’s no reason you should know this) that GitHub came out of the community I was heavily involved in at the time of its birth. I’ve been using GitHub for longer than most people, and so the PR-style workflow has been the air I’ve breathed for so long, it can be hard to understand other things at first. I had used subversion before git, but didn’t really understand much about it.
Anyway, that’s just a roundabout way of saying that I think this space is super interesting because these tools are so flexible that they can be used in so many different ways, and it’s easy to assume that “how you use git” is some sort of shared experience when that’s not really true.
What I find confusing with people raving about it as something different is the considering the following scenario:
refactor/a # should be merged as independent PR
feature/a-b # depends on a; should be merged independently, after
fix/c # independent
Then I will probably have some local `dev` branch checked out with a combination of all of the above and maybe some.
How else than "stacked diffs" would you submit all of this for review concurrently while still working on all of them? It sounds like a new word for what we were always expected to do? What's an alternative which doesn't rely on compromising merge-strategy?
At this point I'm suspecting "stacked diffs" is just a crotch for people still barely coping with DVCS but I could be missing something.
GH did not really support automated base change (after merging) not that long ago, so doing this as stacked diffs/prs there was quite annoying. I guess that's why people tried to avoid it for a long time? I know I did some weird PRs in the past just to keep them independent. It could still be improved today (why is main the base when the branch contains an existing PR? adjust it automatically, please!), but it's not a big issue anymore.
Also this workflow is excruciatingly painful if you need to make a change or add a commit to an earlier part of the “stack”. Now you have to manually rebase everything after it one by one by one.
Yeah, and I think it's also worth noting that by far the largest set of folks advocating for stacked diffs are not actually using git.
Meta runs a custom mercurial-compatible monorepo that was scaled up to handle thousands of commits per hour, and they have a culture of constant codebase-wide refactoring commits (i.e. the ongoing live migration of PHP -> Hack) - that rate of change causes problems that most GitHub projects have no reason to solve.
The holy grail of a stacked diff workflow would be making multiple Github PRs each made against the previous branch instead of trunk, and then updating the branch that's closest to trunk and rebasing all of the children PRs without having to force push into any of them.
Git and Github do not support this workflow directly, and this creates space for all the other tools.
Jujutsu comes close to supporting this workflow directly, without having to provide any specialized utilities that mention "stacked diffs" at all.
https://github.com/spacedentist/spr (not to be confused with ejoffe/spr) is a utility that maps a local change to a remote branch, updating the branch (without force pushes) when the local change is updated. (Changes work the same as they do in JJ, but the implementation is different.) And this works even when you have a stack of changes and update one in the middle of the stack.
Maybe the problem here is that there aren't any open tools implementing the user experience, because I'd say it's exactly the opposite - that it is implemented using rebase under the hood is entirely secondary to the user experience of "stacking" changes on top of one another.
I wonder what it is about descriptions of stacked diffs that doesn't land - it's literally just a rebase-centric workflow instead of the merge-centric workflow popularised by GitHub et al.