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

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 15:08 UTC (Mon) 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

Note, though, that Magit makes things work by saying that you're always dealing with hunks in a commit - it hides the differences between the working copy, the index, and your forest of commits from you. If Magit makes things simpler, then it does so by reducing the number of things you need to juggle in your head by two - get rid of "working copy" and "index" as separate entities.

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 19:25 UTC (Mon) by madscientist (subscriber, #16861) [Link] (7 responses)

> it hides the differences between the working copy, the index, and your forest of commits from you

I don't agree with this.

Staging is visible and important in Magit. It's up-front and clearly distinct. The Magit status buffer shows different sections for the unstaged files, the content of the staging area, and a list of recent commits. And staging files vs. hunks is just a difference in granularity; it doesn't use a separate workflow.

Maybe you mean, it hides the differences in the way you work with the different parts? That might be true to some extent. But it definitely doesn't try to pretend that they are all the same thing; it's more you don't have to remember the various commands and options. For example, it's clear in Magit that neither unstaged or staged hunks are "the same as" a commit.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 21:45 UTC (Mon) by farnz (subscriber, #17727) [Link] (6 responses)

Behaviourally, having used Magit, the staging area behaves exactly the same way as a commit does - it's something you can stage hunks to, and aside from naming it differently, it's possible to make Magit treat the staging area exactly the same as a commit.

Aside from it being given a funny name, it's functionally a commit - you don't get different commands for it, or different options, or different behaviours, or indeed anything to justify treating it specially.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 22:07 UTC (Mon) by madscientist (subscriber, #16861) [Link] (5 responses)

That's not the case. There are many things you can do with staging that can't be done directly with commits (the way things work today).

In addition to staging hunks into the staging area, which could be considered equivalent to amending a commit, you can unstage them again, delete them completely, etc. That is not possible with commits: the only way to modify a commit in that way is to go through a rebase operation.

It's actually more accurate to say that the staging area behaves exactly the same way that the unstaged changes area, except that you can create a commit from the staging area and you can't create a commit directly from the unstaged changes. Other than that staged and unstaged work pretty much identically in Magit, and are treated very differently than commits.

I understand that there could be a different implementation that uses a real commit instead of staging and hides all the work to "unstage" hunks behind the scenes, but that's not how it works and it's not how the mental model is presented.

Jujutsu: a new, Git-compatible version control system

Posted Jan 23, 2024 10:14 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

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.

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.