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

Linux

56374 readers
690 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
nooter692@lemmy.ml
AgreeableLandscape@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.

you are viewing a single comment's thread
view the rest of the comments
[–] atzanteol@sh.itjust.works 4 points 19 hours ago* (last edited 19 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 18 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 18 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 14 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 13 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 13 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 13 hours ago (1 children)

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

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

Don't be stupid.