spr

This looks really interesting. I've been using a similar tool called spr https://github.com/spacedentist/spr for the last six or so months at work. I really like the stacked diff/PR workflow. But spr has a lot of rough edges and im on the lookout for a better alternative. Do you happen to know how your tool compares to spr? How production-ready is it?

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 o

I have been chasing the gerrit code review high since I left a company that used it almost 5 years ago. Stacked pull requests are usually what people point to to get this back, but this article points out that _just_ stacked pull requests don't handle it correctly. Specifically with github, you can't really see the differences in response to code review comments, you just get a new commit. Additionally, often github loses conversations on lines that have disappeared due to force pushes. That said, I have a couple scripts that make it easier to to work with stacks of PRs (the git-*stack scripts in[1]) and a program git-instafix[2] that makes amending old commits less painful. I recently found ejoffe/spr[3] which seems like a tool that is similar to my scripts but much more pleasant for working with stacked PRs. There's also spacedentist/sp

> Another way to look at this that this is 3 linearly dependent PRs masquerading as one. The first commit in the example is not dependent on anything else and may not exist at all. Rather its existence is illusory to show that sometimes when you write commits, a few things happen at once. You might just churn out a doc fix, a bug fix, and a small other thing all at once. It's just the nature of the work. > (on Gitlab you can, not sure about Github) You cannot do this on GitHub without write access to the repository, so it's effectively a non-option for anyone who is not a committer in an open-source context. Don't ask me why this limitation exists. If you do have write access, you can kind of do some similar things like open N pull requests where each PR 1...N has commits 1...N. Then you do something like "Read every PR, then merge only t

Newbie jj convert here. jj is not patch based, like pijul, but snapshots, like git. A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub. However, all is not lost there either: tooling like spr[1] allows you to map between the two universes. At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop. 1: https://github.com/getcord/spr

I use spr and git fixup for this workflow and it's really helped me breakup my changes better, managing multiple branches and stacking changes that way is a huge pain, but this workflow has been huge for me! SPR: https://github.com/getcord/spr Git fixup: https://github.com/keis/git-fixup