| On that first point, there's a use case I sometimes have where stgit feels very clunky: * I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch * I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all) * I want to test and work on the combination of foo and bar and make changes that might need to be updates to some patch in foo, or to some patch in bar At the moment I pick all the patches in foo onto bar in order to do the work and updates in this combined branch, squashing fixes and changes into appropriate patches. Then once I'm happy I go back to the foo branch, blow away the old patches and re-pick them off my combined branch. This works but feels super clunky -- does jj do better here? That would be a real incentive to try it out. For the rest, they don't sound like they're strong enough to beat "I've used stgit for 10 years and have a solid workflow with it". And I just scanned the jj rebase docs and it looks awful, everything I moved to stgit to get away from. I do not want to think about managing a patch stack in terms of "move a bunch of revisions to a different parent". I like having a straightforward stack of patches that I can push, pop and reorder and list. Don't make me think about graphs of commits and multiple rebase suboptions and all that for something that I do all the time in my main workflow, please. |
Combined with jj absorb, some people just work this way all the time, even.
> I like having a straightforward stack of patches that I can push, pop and reorder and list.
You can work this way too, what you'd want is `jj rebase` with -A, -B, and -r: r for the revision, and A and B for the before and after you want to move it too. This lets you reorder things however you want pretty straightforwardly. I tend to work in a stack of patches too, or at least, way more than I used to.