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

Jujutsu: a new, Git-compatible version control system

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

Hmm. The version of Magit I've experimented with allowed me to unstage hunks and delete them from commits, and allows me to create a commit directly from the unstaged changes. Under the hood, it did a rebase operation in the process, but from my perspective it was completely transparent; Magit hid this from me.

From my perspective, Magit is completely hiding the staging area from existence - there's something that behaves just like any other commit, and is called the "staging area", and there's unstaged changes which also behave just like any other commit, but are also present in the working copy on disk, but otherwise Magit makes the differences go away, and just works in terms of moving hunks between the various places in the forest of VCS commits I could see. Perhaps you've configured Magit to be more explicit about the staging area? My configuration for Magit is quite large, and has built up over the last decade.

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 15:48 UTC (Tue) by madscientist (subscriber, #16861) [Link] (3 responses)

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.

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.