I create lots of log files and other temp files when I work. Maybe I just fetched some .json from a service and put it in tmp.json? Maybe I created a small shell script to automate something I'm doing?
You might be able to put them into .gitignore. But why not keep the shell script in a tools folder?
I can see that - but that's a "less frequent" task than me switching between branches.
My observation is that one happens to edit the commit graph much more often because it is so effortless.
And the analogous thing to switching a branch is:
jj
to get the log. And then, with say "qx" being the abbreviated commit id I want to append the next change to:
jj new qx
and now I am already working at the right series of changes.
Because I like a lot to focus on one single thing, the next thing I do is often
jj desc
which opens $EDITOR with the commit description and lets me write down what I am going to add or change.
That commit description also shows up in the log command, so I know always what the change is about.
jujutsu changes a lot of the affordances to manage changes and I understand that many people will be reluctant to use such a changed interface - for one, after they have spent so much time with learning the git CLI, and also because there are dozens of alternative git UIs and VCSes which claim to offer something simpler.
But: jujutsu offers about similar power and flexibility as git, while requiring much less UI complexity. The proof for this is the much, much smaller amount of required documentation as well as practice before one can work productively with it.
All the changed elements give a very orthogonal and cohesive whole, which is very rare for software of that complexity.
Will this work for everyone? Probably not, that happens extremely rarely.
Will many people pick it up on a whim? No, change does not happen that way. In the ideal case, a kind of logistic function but adoption will be very unlikely to be as rapid as git's adoption.
Will experienced git users drop the work they have to do and spend half a day to try a new tool? Some do, and this is good. Some don't, and this is also good.
So, no, I don't have a problem. People have time and decide to look at something or they don't. Both is fine.
More shortcomings of jujutsu:
Some things that are also missing are signing commits and such, but again one can use git for this.
Also, git servers and tools like github, gerrit etc. don't know about jujutsu's change ids, so the advantages are kept local. But this is changing, the tools are adding this metadata.
Also, one can sync up jj repos with rsync, which transmits the change ids.
gitk shows many temporary commits which is distracting.
It obsoletes Emacs Magit, which means vim is the better choice for editing commit messages, which means you see yourself morphing into a vim user. Or maybe emacsclient.
Building jujutsu from source requires a fairly up-to-date Rust environment. (One can download a binary that is statically linked with musl from github but I hate downloading binaries). Debian stable has not even an out-dated version. Building it under Guix's cargo took me some tries.
If you work on a Mainframe or Tandem system, you'll need to wait until your system's Rust port is done. A hefty requirement compared to the needs of building git.
Seeing the list of dependencies makes one wonder whether it was written in node/js.
YMMV but I've found it much easier to manage complex workflows with jj compared
It is no secret that git's interface is a bit too complex - even XKCD has made fun of it.
But what is amusing is that people now have a kind of Stockholm Syndrome, and plain refuse to believe there could be something better.
(Perhaps motivated by the long list of half-assed helper interfaces and GUIs which just were hapless trying to hide the sprawling complexity).
I look forward to read your beautiful, thoughtful, well-commented commit history. No more "Merge branch 'asdfasjkfdlas/alkdjf' into sdkjfls-final" ;-) .
- jj is overeager about adding stuff to ðe repos; it's by design.
One just needs to learn how to un-track stuff, by (1) adding the missing .gitignore entry, (2) issuing the "jj file untrack" ..." command, and (3) removing the file.
The big advantage is the simplification which becomes possible by this: no staging area, no git add / git remove / git commit, no stash save, stash pop, stash apply, and so on. No git amend, fixups, reset soft/hard/ mixed,...
And the overall complexity saving of jujutsu is enormous: two of the man pages on the more complex git commands are already larger and more complicated than all of the jujutsu command line reference (link)- which is pretty complete! And Steve Klabnik's jujutsu tutorial is about a tenth of the length of Beejs brilliant Guide on git. And with Klabnik's Introduction, you can already do more (for example complex rebase operations, like rebasing multiple branches at once).
But, did you try it? Myself, I was comfortable with working with it after one hour or two - after working with git for 18 or 19 years, and often being the first git user in my organization.
The entire point of branches is to have a name that has meaning to me that I can use to refer to work I'm doing.
You already have a name for every change/commit: The first line of the commit message, which you can write when you start work on it.
Branch names in git are temporary: When a branch is merged, its name disappaers.
This is... unforgivably obnoxious.
Well, if you really don't like it after giving it consideration - use git. Nobody forces you to use jujutsu.
Yeah, sort of. It can be used e.g. instead of command-line git commands, or also be intermixed with them. Pushing a branch to a git server works as normal "git push" (needed in older versions with complex vpn/ssh configurations).
Has also still limitations remaining - no git submodule support. But it has work trees.
squashexists but it squashes commits.The rebase command is a bit more flexible but a key difference is handling of conflicts: They represent as regions with conflict markers in the conflicted text regions and all following commits/changes, and they disappear once the conflict has been resolved. No weird interim stated and
git rebase --abort. If you want the old state back, you only need to dojj undoand that's it.