Jujutsu: a new, Git-compatible version control system

Posted Jan 20, 2024 19:53 UTC (Sat) by martinvonz (guest, #169226)
In reply to: Jujutsu: a new, Git-compatible version control system by ceplm
Parent article: Jujutsu: a new, Git-compatible version control system

> Does it mean that `jj` recreates multiple heads hell of Mercurial? If yes, then it is a good reason to stay faaaaar away from it.

No, they are not named branches in the Mercurial sense, they are what Mercurial calls bookmarks (and what Git calls branches).

to post comments

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 3:49 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (3 responses)

There are some people who like to go into detached HEAD mode, create a bunch of garbage commits while they fool around with the codebase, then checkout main (or master or whatever your repository calls it) and implicitly throw away all of those commits. It would be nice if Jujutsu had support for that use case. Unfortunately, I just don't think these ideas are compatible:

* I want the VCS to never lose my data, unless I explicitly discard it (Jujutsu, Mercurial).
* I want the VCS to automatically lose my data, unless I explicitly preserve it (Git).

I'm having a hard time thinking of a coherent UX where you can have both of those options, and you don't accidentally lose a ton of data every now and then from being in the "wrong" mode.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 5:04 UTC (Mon) by thoughtpolice (subscriber, #87455) [Link] (2 responses)

Well, I would say Jujutsu does support throwing your work away. You can throw away vast amounts of work very quickly. But throwing it away implicitly just from changing states is Very Bad and a footgun. git checkout taking you away from detached HEAD to some other place means that you potentially just lost work, but it's frankly a bit strange that a normal command can have ramifications like that. It's why detached HEAD is scary for most people in the first place.

The approach you describe doesn't cleanly map onto the Jujutsu design unfortunately; a lot of the implementation is simplified by the underlying invariant that a snapshot is taken first, that snapshot becoming the working copy commit. And then the commands only ever operate on commits; there are no other states. For example, jj new can just change the current working copy commit, it doesn't need to have any logic to handle the "what if the working tree is dirty case", because it doesn't happen, by definition. Contrast git checkout in your example, where you would be prevented from leaving detached HEAD until you ran git commit -am "garbage" first so that Git doesn't get scared of what might happen.

You can just abandon entire trees of commits in a single command, if that makes any difference to you. For example, if you make 5 garbage commits on top of main starting with the revision xyz, you can just jj abandon -r descendants(xyz) and you're done and those commits are gone. You can also get them back with jj undo if you want. This can be shortened to -r xyz::

The revset language even makes it possible to make this generic, and work independently of the actual change/commit id. For example what if you don't want to even look up the commit id xyz? You can use a revset like -r 'ancestors(@) ~ ancestors(trunk())' where x ~ y means "revisions in x that are not in y", so the whole thing roughly means "The working copy commit and all its ancestors, except those ancestors that are part of the trunk()," the trunk roughly being the main branch on the primary remote. You exclude those ancestors because, well, you can't throw those commits away (they exist upstream). So you can think of the revset language as just a language of sets. You could rephrase this many many ways, for example jj abandon -r '::@ ~ ::main@origin' is the same thing except with some shorthand syntax and referring to the exact remote branch instead. Many things like this are possible; for example "what are all my open patches that have a description that aren't on the remote main branch."

If you want to throw away work, feel free. Jujutsu does not even require you to give a description/commit message for any of these 5 garbage commits. But it won't throw away your work implicitly, and I think for 99.9999999% cases, that's the right move. I think it's just a mindset change, really. And if you throw away the wrong work, it's trivially recoverable; jj undo and jj op log make it very, very difficult to lose data in any meaningful way. I have a hard time really imagining a case where data in Jujutsu gets lost like it can in some cases with Git.

Jujutsu: a new, Git-compatible version control system

Posted Jan 22, 2024 20:12 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

Personally, I don't like this workflow either, and I agree with you that this is a shortcoming of Git. I'm just trying to be charitable towards people who do like Git the way it is.

Jujutsu: a new, Git-compatible version control system

Posted Jan 24, 2024 8:33 UTC (Wed) by marcH (subscriber, #57642) [Link]

> It's why detached HEAD is scary for most people

Obviously.