3 ms·

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

by baq 7mo ago

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.

alphabetag675 7mo ago
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 7mo ago
  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.
VanTodi 7mo ago
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
tinco 7mo ago
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 7mo ago
  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.
VonGallifrey 7mo ago
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.
- baq 7mo ago
  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).
- bilkow 7mo ago
  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+

by baq 7mo ago

alphabetag675 7mo ago

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 7mo ago
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.

VanTodi 7mo ago

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

tinco 7mo ago

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 7mo ago
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.

VonGallifrey 7mo ago

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.

baq 7mo ago
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).
bilkow 7mo ago
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+