Show HN: A visual guide to learning Jujutsu (JJ) • Hacker News Board

Re: Show HN: A visual guide to learning Jujutsu (JJ)

#11

Post by yjftsjthsd-h » Sat, Nov 15, 2025, 5:50 AM UTC

EstanislaoStan wrote: post #6

bfdm wrote: post #4

Maybe I'm out of the loop here, but scanning over this I can't help but ask myself: "Why Jujutsu?" I don't understand what the point is over just using git. The top intro defined some JJ names for git things, but it's not clear why I would want or need this. What problem does it solve with using git?

Ideally, reduces cognitive complexity because you don't have to think about the staging area anymore, just commits. I recently started trying it out at work and I like how fluent it makes what would be more advanced git operations like squashing and rebasing. Issues I've run into have been understanding its version of branches (bookmarks), understanding its merge conflict indicators, and its lack of respect for git s…

> Ideally, reduces cognitive complexity because you don't have to think about the staging area anymore, just commits.

My git use is mostly a direct translation of mercurial (which I learned first), and the staging area is really optional. The only time I ever type `git add` is when adding a new file; otherwise I just

  vi foo.txt
  git commit foo.txt

every time.

I guess jj is different still (by way of ~autocommitting), but my point stands.

Re: Show HN: A visual guide to learning Jujutsu (JJ)

#12

Post by kkfx » Sat, Nov 15, 2025, 2:26 PM UTC

aidenn0 wrote: post #2

The presentation software itself (Excalidraw) makes this nearly unusable for me: When it opened up the entire left-half of my screen is blank, and the diagrams are obviously cut off on the right. There is no apparent way to scroll horizontally (excepting a mouse with a horizontal scroll mechanism of some sort): There is no horizontal scroll bar and neither the arrow-keys nor click-and-drag serve to scroll horizontall…

middle button click&drag or left+right click&drag :)

Re: Show HN: A visual guide to learning Jujutsu (JJ)

#13

Post by [deleted] » Wed, Nov 19, 2025, 2:28 PM UTC

martinvonz wrote: post #9

dietr1ch wrote: post #7

Earlier quoted context omitted.

> Ideally, reduces cognitive complexity because you don't have to think about the staging area anymore, just commits. This is the thing I don't like about jj. I know it makes splitting easy, but splitting is harder than selectively adding after blindly merging all changes.

> but splitting is harder than selectively adding after blindly merging all changes. Is the scenario that you make many changes in the working copy and then run `git add -p` a few times until you're happy with what's staged and then you `git commit`? With jj, you would run `jj split` instead of the first `git add -p` and then `jj squash -i` instead of the subsequent ones. There's no need to do anything instead of `gi…

[deleted]

Re: Show HN: A visual guide to learning Jujutsu (JJ)

#14

Post by dietr1ch » Wed, Nov 19, 2025, 3:11 PM UTC

martinvonz wrote: post #9

dietr1ch wrote: post #7

Earlier quoted context omitted.

> Ideally, reduces cognitive complexity because you don't have to think about the staging area anymore, just commits. This is the thing I don't like about jj. I know it makes splitting easy, but splitting is harder than selectively adding after blindly merging all changes.

> but splitting is harder than selectively adding after blindly merging all changes. Is the scenario that you make many changes in the working copy and then run `git add -p` a few times until you're happy with what's staged and then you `git commit`? With jj, you would run `jj split` instead of the first `git add -p` and then `jj squash -i` instead of the subsequent ones. There's no need to do anything instead of `gi…

> This scenario seems similarly complex with Git and jj.

It is in number of commands ran, but there's a few annoyances around changes getting into the repo automatically.

There's a lot of git commits coming from jj's constant snapshots. Maybe this is a good thing overall, but it brings some silly issues,

What to do when data that shouldn't leave the dev machine gets to the repo? I'm thinking secrets, large files, generated files. - Leaking secrets by mistake seems easier. - Getting large files/directories into the git snapshots might degrade git's performance.

It seems that you need to be diligent with your ignores or get forced to learn more advanced commands right away. I guess there's a more advanced history scrub command around though.