this post was submitted on 02 Aug 2025
33 points (88.4% liked)

Programming

23971 readers
90 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

“Jujutsu (jj) is a version control system with a significantly simplified mental model and command-line interface compared to Git, without sacrificing expressibility or power (in fact, you could argue Jujutsu is more powerful). Stacked-diff workflows, seamless rebases, and ephemeral revisions are all natural with jj [...]”

Part 2 of the series is out and is here.

you are viewing a single comment's thread
view the rest of the comments
[–] atzanteol@sh.itjust.works 1 points 4 months ago (27 children)

Jujutsu does not use branches much because you are focused on the nodes in the commit graph. And instead of giving every of them manually a name, they are identified with change IDs.

This is... unforgivably obnoxious. What's the point of this? That's like saying "Instead of giving every directory a name manually you identify them by inode." The entire point of branches is to have a name that has meaning to me that I can use to refer to work I'm doing.

As soon as you edit a file, the changes will be included in whatever revision you're currently editing—there's no separate staging area in Jujutsu.

I create log files of runs, temporary helper scripts, build output, etc. in my working copy all the time. And this thing is going to "save me the burden" of having to add files manually by just adding... everything it sees.

You'll have noticed that at no point so far did we ever think about creating a branch. That's because Jujutsu's relationship to branches is a bit different to Git's—they're just pointers that you move around so they point to whichever revision you want them to at a given time.

"Simpler" apparently means I get to do a lot more book-keeping than when I use git.

[–] HaraldvonBlauzahn@feddit.org 2 points 4 months ago* (last edited 4 months ago) (3 children)

But, did you try it? Myself, I was comfortable with working with it after one hour or two - after working with git for 18 or 19 years, and often being the first git user in my organization.

[–] atzanteol@sh.itjust.works 2 points 4 months ago (2 children)

I've started to tinker with it. "auto commit everything" is an absolute deal-breaker for me. There's no world in which I want every file I create to be added to source control without asking. I create lots of log files and other temp files when I work. Maybe I just fetched some .json from a service and put it in tmp.json? Maybe I created a small shell script to automate something I'm doing? I guarantee I'm going to end up pushing that shit upstream by accident at some point.

[–] ranting_sandfish@mander.xyz 2 points 4 months ago

Luckily you can turn it off and use the standard 'add' workflow. I did that almost reflexively when I started trying to use jj. (snapshot.auto-track)

However, over time, and once I got the .gitignore fully set up for bigger projects, I've come around on re-enabling autocommit for more of my repos. It does flow pretty naturally once you have an established process. I find it enables both better 'undo', and more seamless context-switching.

You can also set a more specific snapshot.auto-track on a repo or user basis for personal tooling conventions that don't make sense to gitignore.

load more comments (1 replies)
load more comments (1 replies)
load more comments (24 replies)