Jujutsu is essentially an alternative front-end or “porcelain” to git, both magnificiently simplified and powerful.
I tried it after using Emacs Magit for about six or seven years, and jujutsu is really easier to use than git and useful if one wants a tidy public history of changes (with “tidy” and “public” as Linus Torvalds recommends). Plus it is fully compatible to git as backend - other contributors will not even note you are using it.
Ooooh, that’s interesting.
Technically true - but it looks like
jjdoes a lot of history re-writing which would require a lot of care to be taken when working on a shared codebase.The page on remotes has some cautions in it.
jjby default refuses to change any commits on published branches such as a master branch that has been pushed. The details are configurable.BTW that’s why I linked Linus Torvalds mail on when and why to rewrite history - it is good advice.
Another useful property is that while jujutsu does have worktrees, like git, in many cases where one would use git worktrees (for example when writing accompanying documentation ) it is just easier to use another line of changes (what is a branch in git).
Alas, that jujutsu does not store local change sets automatically on a remote git repo (this happens only when you update and push a git branch), means that still-mutable local changes are not automatically transferred to another computer you work on. And unpublished changes are naturally mutable in jujutsu. But you can safely copy a jj repo via rsync, as changes in jj metadata are thread-safe and atomic. The other way is of course to push a work-in-progress (“WIP”) git branch which can muate and is therefore not allowed to be merged by other people.
deleted by creator
One difference between using worktrees and branches in git is that in git you usually have uncommited stuff that’s not finished, and worktrees are a way to avoid committing this. And you want to avoid committing early because it is hard to clean-up later. This hesistsnce to commit is not necessary at all in jujutsu - any change to the source files is already captured and will be restored once you go back to that changeset. There are other cases where you use worktrees in git e.g. to isolate a build and an hour-long integration test running it in parallel to your ongoing work, and in thar cases, you’d use workspaces in jujutsu like you’d in git.
Too many commands that do subtly and irreversivly things on the repo, with potentially messed-up interim states, only to do the conceptually much simpler task to edit and manipulate the directed acyclic graph of commits.
In short, jujutsu is a commit graph editor and does the same with perhaps 10% of the complexity of git. The man pages on the git reset, branch and merge commands are already larger than the whole - and detailed!- documentation of jujutsu.
Steve Klabnik explains this much better than I can here in his blog that I posted.
deleted by creator
I have to admit that in spite of having used git for about 20 years, I never used reflog. And even with magit I did stuff like rebase rarely. I found it costing too much time to read the man pages again every time and meditate what would happen with “reset xyz”.
deleted by creator
Now, jujutsu covers almost the same with < 10% of that complexity and less than 10% of the documentation - simpler but the same power.