Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Posted Jan 20, 2024 16:51 UTC (Sat) by martinvonz (guest, #169226)In reply to: Jujutsu: a new, Git-compatible version control system by apoelstra
Parent article: Jujutsu: a new, Git-compatible version control system
Yes, I think most users do resolve conflicts pretty much as soon as they arise.
> Talk of dropping `rebase --continue` raises my eyebrows. I hope that there continues to be a notion of `rebase -i` where you can edit specific commits, and where you can choose to fix conflicts mid-rebase so that they don't cascade too much.
Cascading conflicts isn't really a problem, thanks to the simple algebra we do on the conflict representation (https://martinvonz.github.io/jj/prerelease/technical/conf...). After rebasing a stack of commits where you end up with conflicts, you would check out the first commit with conflicts, resolve those conflicts, and then squash the conflict resolution into the conflicted commit. The descendants are then automatically rebased, and the conflict resolution is effectively applied to each descendant. If there were other conflicts further down the stack, you would then check out that commit and continue the process. Even if these conflicts touched the same code as the conflict you just resolved, they would have been simplified (terms cancel out in the algebra) at this point, so they would be regular 3-way conflicts.
> I can't use jj without signed commits and I wouldn't want to without workspaces, but those don't sound conceptually hard, just low priority.
Workspace are actually supported (https://martinvonz.github.io/jj/prerelease/working-copy/#...). Support for signing commits is close to done (https://github.com/martinvonz/jj/pull/2728).
> The git comparison page also says that it lacks a "current branch" and named branches in general...not sure whether this is a principled stance or a matter of development priorities. From a user POV I think these are pretty important features, even if technically there is no longer any garbage collector to guide.
Named branches are actually supported. What we meant by "No need for branch names" is just that you don't have to create a branch for a commit to remain visible or to prevent GC of it. There's instead a `jj abandon` for when you want to get rid of a commit. I've sent a PR to try to clarify that branches are supported.
I wouldn't mind a "current/active branch" concept. I think we just haven't found that it's worth the extra UX complexity yet. https://github.com/martinvonz/jj/discussions/2425 has some discussion about it.
> (Also how does garbage collection work if every tip is kept around?)
Objects not reachable from the operation log are eligible for garbage collection. As you imply, that means that practically no objects are eligible, because they have been reachable at some point in time. So we have a `jj op abandon` command for abandoning old operations you, which makes some old objects eligible for garbage collection. This is similar to how Git's reflog prevents garbage collection but has commands for expiring reflog entries, allowing objects to be collected.
> As others have said, the messaging needs a bit of tweaking -- e.g. "index is unnecessary" sort of phrasing sounds so much like other projects' "we threw away the index because it confused users who had first been shown a computer five minutes ago".
Thanks for the feedback. We tried to improve that a while ago, but we clearly still have work to do there.
> In some ways it's the opposite of Fossil -- from "rebasing is evil" to "rebasing should be done constantly behind the scenes" :) Probably they'll need to add some UX-layer stuff to warn users about this or require confirmation when replacing pushed commits.
We have a configurable set of "immutable commits" (configured by a "revset", https://martinvonz.github.io/jj/prerelease/revsets/). Commands that attempt to rewrite such commits will error out. The set defaults to the "trunk" commit and tagged commits (ancestors are implicitly immutable).
Posted Jan 20, 2024 17:38 UTC (Sat)
by apoelstra (subscriber, #75205)
[Link]
BTW in git I usually completely disable the garbage collector -- I work on very few projects large enough to feel the disk space or performance hit. Sometimes I find myself scribbling bare commit IDs onto paper or into some other journal, before abandoning something that I'm unlikely to care about again. It would be very nice if there were some facility for "anonymous branches" that I could keep around Just In Case, and it sounds like the operation log provides exactly this.
Posted Jan 20, 2024 19:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
> Thanks for the feedback. We tried to improve that a while ago, but we clearly still have work to do there.
Just say you don't have a git style index because it doesn't sit well with the way you work, but you have the equivalent which works even better :-) Or say that index is a uniquely git fix and you do it differently. Or whatever, just stress that you're different, and your solution to the problem is different. The current vibe apparently implies you don't acknowledge the underlying problem, and THAT is your problem.
Cheers,
Posted Jan 20, 2024 19:58 UTC (Sat)
by martinvonz (guest, #169226)
[Link] (3 responses)
Right, that's what we've tried to do.
> The current vibe apparently implies you don't acknowledge the underlying problem, and THAT is your problem.
Can you point to where you got that impression? I can understand if one gets that impression by seeing just "There's no index (staging area)." out of context. Do you think that's what people do? (I do want to clarify the text, but I want to fix it in the right place(s), and I just don't know where it's currently most confusing.)
Posted Jan 20, 2024 20:55 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
There's no index (staging area). Because the working copy is automatically committed, an index does not make sense. Git workflows that rely on the index can be simply achieved using native jujutsu commands instead.
Cheers,
Posted Jan 20, 2024 21:00 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
Personally, it sounds to me like a jujutsu porcelain over git with this approach might be an excellent idea ... :-)
Cheers,
Posted Jan 20, 2024 22:02 UTC (Sat)
by martinvonz (guest, #169226)
[Link]
Ah, it took me a while, but I see what you mean now. Thank you! I sent https://github.com/martinvonz/jj/pull/2856 to try to improve it.
Posted Jan 20, 2024 19:31 UTC (Sat)
by ceplm (subscriber, #41334)
[Link] (5 responses)
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.
Posted Jan 20, 2024 19:53 UTC (Sat)
by martinvonz (guest, #169226)
[Link] (4 responses)
No, they are not named branches in the Mercurial sense, they are what Mercurial calls bookmarks (and what Git calls branches).
Posted Jan 22, 2024 3:49 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
* I want the VCS to never lose my data, unless I explicitly discard it (Jujutsu, Mercurial).
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.
Posted Jan 22, 2024 5:04 UTC (Mon)
by thoughtpolice (subscriber, #87455)
[Link] (2 responses)
Posted Jan 22, 2024 20:12 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
Posted Jan 24, 2024 8:33 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Obviously.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
* I want the VCS to automatically lose my data, unless I explicitly preserve it (Git).
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. Jujutsu: a new, Git-compatible version control system
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
Jujutsu: a new, Git-compatible version control system