zlacker

[return to "Stacked Diffs with git rebase —onto"]
1. swaits+JWe[view] [source] 2025-12-05 13:31:28
>>flexdi+(OP)
Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?”

You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference).

I’ve wondered if there is a psychological thing here: someone who spent time memorizing all the git nonsense may have some pride in that (which is earned, certainly), that introduces some mental friction in walking away???

◧◩
2. unshav+dhf[view] [source] 2025-12-05 15:10:00
>>swaits+JWe
Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj:

1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work is the branch, with specifically named branches, my `jj ls` was confusing as hell.

`jj st` might have helped a bit, but there were scenarios where creating an commit would abandon the branch... if i'm reading my post history correctly. My coworker who was more familiar explained my jj problems away with "definitely pre-release software", so at the time neither of us were aware of a workflow which considered branches more core.

Fwiw, I don't even remember when the jj workflow had branches come into play.. but i was not happy with the UX around branches.

2. iirc i didn't like how it auto stashed/committed things. I found random `dbg!` statements could slip in more easily and i had to be on guard about what is committed, since everything just auto pushed. My normal workflow has me purposefully stashing chunks when i'm satisfied with them, and i use that as the visual metric. That felt less solid with jj.

Please take this with a huge grain of salt, this is 10 month old memory i scavenged from slack history. Plus as my coworker was saying, jj was changing a lot.. so maybe my issues are less relevant now? Or just flat out wrong, but nonetheless i bounced off of jj despite wanting to stick with it.

◧◩◪
3. oscill+6rf[view] [source] 2025-12-05 15:51:58
>>unshav+dhf
I more or less use the method described [here](https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `jj bookmark set branch_name -r @`
◧◩◪◨
4. conrad+OVg[view] [source] 2025-12-05 23:13:54
>>oscill+6rf
_Every time I see one of these nifty jj tricks or workarounds I find myself wondering, “why not just use git?”_
◧◩◪◨⬒
5. stevek+V2h[view] [source] 2025-12-06 00:10:35
>>conrad+OVg
How would you do this in stock git?
◧◩◪◨⬒⬓
6. wild_e+nth[view] [source] 2025-12-06 04:38:15
>>stevek+V2h
I might just not be following correctly but committing in git just carries the branch along for the ride, so there's nothing to do in git for this scenario.

IIRC forcing some specific branch name to point to my changes with `jj` was non-obvious and what made me give up and go back to git when I tried it last year.

◧◩◪◨⬒⬓⬔
7. oscill+Dwi[view] [source] 2025-12-06 17:01:15
>>wild_e+nth
You are mistaken. In the workflow I described, I am making changes on top of all branches at once and then deciding which branch to send the new commit to. This allows me to make changes simultaneously to both branches without friction.
[go to top]