20 ms·

The way I understand it, its for those who can't help but to fix B while working on A and want to make sure that they are two different PRs? The way I do it is

• nchmy 1y ago
  You'd probably like reading about the megamerge workflow. I and others have linked some articles in a few comments here already.
• stouset 1y ago
  Yep! And it makes it convenient even when you need to make changes or add new commits onto A. B is constantly stitched up to remain a child of A and incorporate its fixes. It also makes it simple and easy to split B and A apart such that both their parents are `main` if they’re unrelated. You can also go hog-wild. I was working on a big refactor recently. I made independent changes A, B, C, and D (each one to three commits). I then wanted to work on code that assumed all of these commits were available, so I made a merge commit E that combined them. I then made changes F that depended on that refactor, so was a child of E. Managing this was simple. If I needed to make updates or tweaks to A-D, E and F were updated to incorporate them automatically. `jj absorb` even meant that doing these types of changes was almost zero work: I could make a bunch of changes and the tool would know in which parent commit they belonged. None of this was merged in yet. When I was ready, PRs went out for A-D. When they each merged into `main`, E became a no-op and was discarded. F became its own PR. This is something I never would have done in git because having multiple threads of unmerged code is a colossal hassle.