Jujutsu: a new, Git-compatible version control system [LWN.net]

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 15:48 UTC (Tue) by madscientist (subscriber, #16861)
In reply to: Jujutsu: a new, Git-compatible version control system by farnz
Parent article: Jujutsu: a new, Git-compatible version control system

I'm using the latest version (or at least within the last week or two: I haven't restarted my Emacs session in a while :))

It's true that you can ask to "unstage" a hunk in a commit, but what happens is that Magit will add a staged change that reverts that hunk, then an unstaged change that adds it back again. You can choose which one you want and if you want to keep the revert you can apply that change either by adding a new revert commit or by using Magit's fixup facility (which makes a commit then uses rebase to squash it into the original commit, but done for you).

It is pretty different from a UI perspective to unstaging a hunk from the staging area, which simply moves it back to unstaged as if you'd never staged it at all.

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 15:51 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

I've never seen that UI behaviour from Magit; you have it set up differently to me (I copied someone else's config ~10 years ago to get started, and stuck with that). I don't ask it to unstage a hunk; I ask it to move hunks between locations, and the staging area is just one of those locations. I can literally ask Magit to move a hunk straight from the commit to the unstaged work, or to the staging area, or to another commit, and it works out what sequence of operations makes that happen for me.

In this setup, there's no need for the staging area - it's just a commit with a funny name - as all the "move hunk" operations work just as well between two commits as they do between a commit and the staging area.

Jujutsu: a new, Git-compatible version control system

Posted Jan 26, 2024 16:44 UTC (Fri) by madscientist (subscriber, #16861) [Link] (1 responses)

This is probably too off-topic to continue much further.

I don't know what keys/commands you are using to get the behavior you see, but I'm using bog-standard Magit with all the basic settings and very little customization. The key I use to unstage a hunk is "u". If the cursor is on a hunk that's been staged, then the hunk is moved back to "unstaged changes" by pressing that key. If the cursor is on a hunk in a commit (I view the hunks in the commits by selecting a commit in my "Recent Commits" list then pressing ENTER to see its changes) then I get the behavior I described previously.

Perhaps you are entering some other "commit editing mode" in Magit, that I'm not using. It sounds cool! But in any case there is a clear difference in the UI behavior between staged hunks and hunks in commits.

Jujutsu: a new, Git-compatible version control system

Posted Jan 30, 2024 12:32 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I think it's that Magit can display them differently, but under the hood Magit tries to paper over the difference (internally) by making actual commits for the stage behind the scenes.