3 ms·

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 som

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.

Kinrany 2y ago
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 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.
- steveklabnik 2y ago
  The https://github.com/sunshowers/spr https://github.com/sunshowers/spr fork supports jj :)
  - Kinrany 2y ago
    Beautiful, thank you!
swiftcoder 2y ago
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.
3np 2y ago
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.
- viraptor 2y ago
  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.
  - stouset 2y ago
    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.
- ykonstant 2y ago
  A crutch, I think. Or a crotch; I don't judge.

Kinrany 2y ago

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 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.

steveklabnik 2y ago
The https://github.com/sunshowers/spr https://github.com/sunshowers/spr fork supports jj :)
- Kinrany 2y ago
  Beautiful, thank you!

swiftcoder 2y ago

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.

3np 2y ago

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.

viraptor 2y ago
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.
- stouset 2y ago
  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.
ykonstant 2y ago
A crutch, I think. Or a crotch; I don't judge.