does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count?

if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.

▲ tinco 9 hours ago | parent | next [-]

It might count, but it is easy with git as well, what is the feature in jj that makes this easier? Switching branches and pushing changes to remotes is the core feature of git and in my opinion really easy so I'm curious how jj improves on it.

	▲	baq 8 hours ago \| parent [-]
		rebases don't lose branches and jj absorb trivially squashes changes to the correct head (or leaves changes alone if it can't find where to squash). is it possible in git? yeah, I've done it; there's a reason I haven't done it more than a few times with git, though. ergonomics matter.

▲ VanTodi 9 hours ago | parent | prev | next [-]

Guess he was talking about the presentation, not what the tool can achieve. It has no hard proof on the first page, which could easily just be a LinkedIn pitch, but not on hackernews

▲ VonGallifrey 9 hours ago | parent | prev | next [-]

Can you show how you would do this in jj?

I know how I would do this in git, but don't really see how this would be in jj. I currently don't use it in my workflow, but if it is super easy in jj then I could see myself switching.

	▲	bilkow 8 hours ago \| parent \| next [-]
		This is how I'd do it: `jj new branch1 branch2 branch3` This creates an empty commit that merges all 3 branches, you can think of this as your staging area. When you want to move specific changes to an existing commit, let's say a commit with an ID that starts with `zyx` (all jj commands highlights the starting characters that make the commit / change unambiguous): `jj squash -i --to zyx` Then select your changes in the TUI. `-i` stands for interactive. If you want to move changes to a new commit on one of the branches: `jj split -i -A branch1` Then select the changes you want moved. `-A` is the same as `--insert-after`, it inserts the commit between that commit and any children (including the merge commit you're on). There's one thing that's a bit annoying, the commit is there but the head of the branch hasn't been moved, you have to move it manually (I used + to get the child to be clearer, but I usually just type the first characters of the new change id): `jj bookmark move branch1 --to branch1+`
	▲	baq 8 hours ago \| parent \| prev [-]
		the beauty of it is there's not much to show; I use a crude jjui approach where I have an octopus merge working tree commit (in command line terms, jj new PR_A PR_B PR_C) and either use native jj absorb (S-A in jjui) which guesses where to squash based on the path or, when I'm feeling fancy, rebase the octopus via jjui set parents (S-M) function (also handy to clean up parents when one of the PRs gets merged).

▲ alphabetag675 9 hours ago | parent | prev [-]

Actually it is a anti-demo, because while software allows you to do it, I don't think many software engineers can work on this.

	▲	baq 8 hours ago \| parent [-]
		in large enough monorepos and teams and big enough changes you either do it like this or have a humongous giga-PR which eventually starts conflicting with everything.