[amomchilov]

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews.

Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

[Cthulhu_]

Check out the rebase.updateRefs option: https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c

[Too]

git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong.

One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly and reorder the commits with interactive rebase to insert the revert first. It’s a bit hard to explain without an example, once you’ve tried it you will understand.

[baq]

> as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong.

A vcs can allow you to commit conflicts and then commit their resolutions whenever necessary. This has been pioneered by darcs (IIRC) and jj also allows that.

[raylu]

`git rebase -i` lets you reorder one branch of commits easily

in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases

one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)

[theappsecguy]

Try git-spice!