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. mwcz+THf[view] [source] 2025-12-05 16:58:57
>>swaits+JWe
I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does.

jj is harder to adopt for people with a thorough mental model of git, because it's harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.

People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.

◧◩◪
3. stevek+qPg[view] [source] 2025-12-05 22:33:00
>>mwcz+THf
Glad you like that I like it!

What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.

I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:

With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.

With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.

... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.

[go to top]