this post was submitted on 14 Jul 2025
42 points (88.9% liked)

Linux

56371 readers
623 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
42
Introduction - Steve's Tutorial on Jujutsu, an alternative front-end to git (steveklabnik.github.io)
submitted 1 day ago* (last edited 1 day ago) by HaraldvonBlauzahn@feddit.org to c/linux@lemmy.ml
20 comments fedilink hide all child comments
 

Jujutsu is essentially an alternative front-end or "porcelain" to git, both magnificiently simplified and powerful.

I tried it after using Emacs Magit for about six or seven years, and jujutsu is really easier to use than git and useful if one wants a tidy public history of changes (with "tidy" and "public" as Linus Torvalds recommends). Plus it is fully compatible to git as backend - other contributors will not even note you are using it.

top 20 comments
sorted by: hot top controversial new old
[–] atzanteol@sh.itjust.works 4 points 17 hours ago* (last edited 17 hours ago) (2 children)

Hrm... It looks interesting but it seems too dedicated to crafting "the perfect commit".

Changing our description changed the commit ID! This is why we have both IDs: the change ID has not changed, but the commit ID has. This allows us to evolve our commit over time, but still have a stable way to refer to all versions of it.

I don't want to "evolve a commit" - I want to capture my changes over time. If I decide later that I want to prepare the commit for merging I will.

I hate it because it's different - but even trying to give it a "benefit of the doubt" I really can't see this as better. It's not like it's difficult to create a "tidy" commit with git as is.

And as far as "easier to use goes"... well... Here's how you get a list of anonymous branches

jj log -r 'heads(all())'

And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?

jj new pzoqtwuv yykpmnuq -m "merge better documentation"
# vs. 
git merge my_branch_Name

I'm unconvinced. Though jj undo looks neat (and also crazy dangerous unless you can undo an undo?).

[–] HaraldvonBlauzahn@feddit.org 1 points 16 hours ago

And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?

No trouble, you can still name branches if you want. And no, you don't have to type the whole changeset hash, the first one to three letters are usually sufficient.

Also, branch names are not a permanent thing, they disappear after you merged them.

If you want, to can put an empty commit with the description of what you want to do at the top of your changes, and then use "jj split" to move changes to different commits before it. There are several common work flows which are explained in Klabnik's blog post.

[–] HaraldvonBlauzahn@feddit.org 0 points 16 hours ago (1 children)

Yeah you can undo undo and also resurrect undone states.

If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it's possible that jj does not give you enough advantage. Everyone works different.

[–] atzanteol@sh.itjust.works 2 points 13 hours ago (2 children)

If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it’s possible that jj does not give you enough advantage. Everyone works different.

I mean... It does and I will use git to manage commit histories as necessary. I don't see jj as solving that problem or even making it easier. Doing a single squash-commit or a rebase -i when I merge a branch is relatively trivial.

And from what I can tell it's much easier to do a git pull upstream master than to do jj new skdfsld dskfjas since you'll likely have to lookup those hashes? I mean I wouldn't remember them.

[–] HaraldvonBlauzahn@feddit.org 1 points 12 hours ago (1 children)

And from what I can tell it's much easier to do a git pull upstream master than to do jj new skdfsld dskfjas since you'll likely have to lookup those hashes? I mean I wouldn't remember them.

One takes them from the last commit log and uses the first few letters. Steve Klabnik shows how they are used in practice. It makes no sense to repeat it here.

[–] atzanteol@sh.itjust.works 2 points 11 hours ago

One takes them from the last commit log and uses the first few letters

So - it's not the length of the random garbage that is the issue it's the fact that it's random garbage that I have no chance of remembering after 5 seconds and switching between branches. All my branches are instead random hashes that I'll need to lookup or remember.

I've read through the blog. It sounds like they've taken the minor inconvenience of doing a git merge --squash and distributed that pain across every-single-commit you're ever going to make instead. All to get "tidy commits" which were possible before anyway.

I was actually rather interested in the idea of jj being something that made history-rewriting easier (e.g. for removing bad commits with passwords and the like). But the fact that it almost completely throws out the entire concept of working on named branches (yes you can have them - but "One interesting thing about branches in jj that's different than branches in git is that branches do not automatically move." - genius) is just ridiculous. And to claim that it's now simpler just seems like gaslighting.

[–] HaraldvonBlauzahn@feddit.org -1 points 12 hours ago (1 children)

So you think that git has already a perfect user interface?

[–] atzanteol@sh.itjust.works 1 points 11 hours ago

Don't be stupid.

[–] priapus@piefed.social 2 points 17 hours ago

I highly recommend giving Jujutsu a try. It didnt take long to learn at all and just feels so much more flexible and intuitive.

[–] paequ2@lemmy.today 7 points 1 day ago (2 children)

other contributors will not even note you are using it.

Ooooh, that's interesting.

[–] atzanteol@sh.itjust.works 3 points 17 hours ago (1 children)

Technically true - but it looks like jj does a lot of history re-writing which would require a lot of care to be taken when working on a shared codebase.

The page on remotes has some cautions in it.

We need the --allow-backwards flag to set the trunk branch to the previous commit because it is a dangerous operation: if we had pushed trunk, things would get weird when we try and push now. We've kept it all local, so there's no issues with doing this.

[–] HaraldvonBlauzahn@feddit.org 1 points 16 hours ago* (last edited 16 hours ago)

jj by default refuses to change any commits on published branches such as a master branch that has been pushed. The details are configurable.

BTW that's why I linked Linus Torvalds mail on when and why to rewrite history - it is good advice.

[–] HaraldvonBlauzahn@feddit.org 0 points 1 day ago* (last edited 1 day ago) (1 children)

Another useful property is that while jujutsu does have worktrees, like git, in many cases where one would use git worktrees (for example when writing accompanying documentation ) it is just easier to use another line of changes (what is a branch in git).

Alas, that jujutsu does not store local change sets automatically on a remote git repo (this happens only when you update and push a git branch), means that still-mutable local changes are not automatically transferred to another computer you work on. And unpublished changes are naturally mutable in jujutsu. But you can safely copy a jj repo via rsync, as changes in jj metadata are thread-safe and atomic. The other way is of course to push a work-in-progress ("WIP") git branch which can mutate and is therefore not allowed to be merged by other people.

[–] ugo@feddit.it 1 points 1 day ago* (last edited 1 day ago) (1 children)

That’s not really how one would use worktrees in git. Worktrees are useful in the case when e.g. you are working on version 0.15 of your software that has many breaking changes to version 0.14 (perhaps even on a build system level) and you need to release a 0.14.1 patch. Worktrees separate directories which means you don’t need to stash or do a wip commit, nor clear you 0.15 build artefacts. Just cd to a different worktree, checkout the 0.14 branch, create and checkout the 0.14.1 branch, clear build artifacts in a different directory from your main development one, and start working.

When done, just cd back and keep working again without switching branches, clearing artifacts, or doing full rebuilds of the in-development 0.15 version.

Plus, git does not store change sets or branches or anything on any remote unless you push them either, so if you’re having that problem just stop pushing things you don’t want to push. You can totally rsync a git repo, just ensure it’s at rest. Otherwise do what you should be doing anyway: set the repo on another machine as a remote of the other repo, so you can git pull my_private_machine feature/my_private_branch without needing to push to a central repo.

I’m sure jujutsu has many advantages, but it also reads to me like you’re misunderstanding the git model. Which can be a fair critique of git to be fair, but then we would need to talk about what about the git model people have trouble with, why, and how to address those issues, and so far I haven’t seen any kind of research in that direction from jujutsu (not that I’ve been looking particularly hard)

[–] HaraldvonBlauzahn@feddit.org 1 points 1 day ago* (last edited 1 day ago) (1 children)

One difference between using worktrees and branches in git is that in git you usually have uncommited stuff that's not finished, and worktrees are a way to avoid committing this. And you want to avoid committing early because it is hard to clean-up later. This hesistsnce to commit is not necessary at all in jujutsu - any change to the source files is already captured and will be restored once you go back to that changeset. There are other cases where you use worktrees in git e.g. to isolate a build and an hour-long integration test running it in parallel to your ongoing work, and in thar cases, you'd use workspaces in jujutsu like you'd in git.

but then we would need to talk about what about the git model people have trouble with, why

Too many commands that do subtly and irreversivly things on the repo, with potentially messed-up interim states, only to do the conceptually much simpler task to edit and manipulate the directed acyclic graph of commits.

In short, jujutsu is a commit graph editor and does the same with perhaps 10% of the complexity of git. The man pages on the git reset, branch and merge commands are already larger than the whole - and detailed!- documentation of jujutsu.

Steve Klabnik explains this much better than I can here in his blog that I posted.

[–] ugo@feddit.it 1 points 22 hours ago (1 children)

It is simply not my experience that cleaning up commits after committing early is difficult in git. Amending a commit is a single -a flag away from the git commit command. The opposite problem is when you do too much work and want to split it into multiple commit rather than a huge one, in which case git add -p is again a single flag away from git add.

In general, git’s entire model is to allow you to work first, and do administrative tasks (including tidying up your commit history etc) later.

And almost nothing is truly destructive in git, the vast majority of cases can be fixed by judicious use of git reflog.

The only cases I’ve ran into where git repos became corrupted were caused by external tools, mainly GUIs that label buttons with git commands that do something different when clicked (like the button labeled push actually doing git push —all for no good reason, and such things) with users that have no idea how git works that have been trained just by telling them “click this to save your work, click this to get the last version of the code”

[–] HaraldvonBlauzahn@feddit.org 1 points 16 hours ago* (last edited 16 hours ago) (1 children)

I have to admit that in spite of having used git for about 20 years, I never used reflog. And even with magit I did stuff like rebase rarely. I found it costing too much time to read the man pages again every time and meditate what would happen with "reset xyz".

[–] ugo@feddit.it 0 points 16 hours ago (1 children)

Fair, git’s documentation can definitely be too terse despite being very extensive and could really benefit from examples and common use cases sections. I only use a fraction of what git offers, but what I do use I use often, which definitely contributes to my happiness with git: I seldomly need to look things up

[–] HaraldvonBlauzahn@feddit.org 1 points 12 hours ago

Now, jujutsu covers almost the same with < 10% of that complexity and less than 10% of the documentation - simpler but the same power.

[–] ViatorOmnium@piefed.social 1 points 1 day ago

Currently it works just as frontend for git, but it theoretically supports other backends too. Allegedly Google has their own experimental internal cloud+db based backend for big monorepos.