Jujutsu VCS: Introduction and patterns

1. No branches. Instead of having tunnel vision on a single branch, you can easily hop around the tree, creating revisions and switching context without having to mess about stashing files and then remembering which branch and version each stash is for. The fact that your changes are automatically added to a revision make this very easy. You can literally drop what you're doing, `jj edit` or `jj new` a different commit to switch over to working on that stuff, whether it's on a Git branch or not.

For example, you could be working on a feature 'A', push your PR and then start work on feature 'B', only to find your pipeline has failed thereafter. You can then `jj new` a commit off your old feature commit, create a fix and push it (or even `jj squash` it first) and then `jj edit` back over to what you were doing on feature 'B' with no fiddly stashes.

2. Much simpler rebasing commands. For those of us who like to rewrite history to make PRs easier to comprehend for reviewers, and for general rebasing when your target branch has changes, I find the `jj rebase` much saner than Git. It's very easy to rebase a set of commits or move a single commit about in history.

`jj squash` is also great for fixing up earlier commits. You can `jj new` a commit off an existing commit, make a fix or change and then `jj squash` it into the previous one without a fiddly `git rebase -i HEAD~2`.

3. Automatically rebasing of descendents. If I edit a commit in the history, all of the descendents are automatically rebased with this change. So if I realise I've made a mistake in commit `aaa` and edit that commit, `bbb` and `ccc` that are derived from it will automatically incorporate this change, with commits being market conflicted if this can't be done.

4. Conflict handling. Any conflicts are recorded against commits and doesn't prevent operations from working. So you don't have to immediately drop everything and work interactively through a set of conflicts. Combine that with the automatic rebasing, above, and your resolutions propagate through the descendents similar to using git rerere.

So those, for me, are the killer features.

On the downsides:

1. HTTPS Git repository handling is poor. There is no vault integration, at least on Mac, so I have to enter my username and password every time. This is not a problem for SSH, but my company prohibits SSH, so it's a pain. ** see reply below, credential helper now works **

2. Git fetches seem slower for large changes than using Git fetch directly, and I've had the tool timeout on repositories with large files. Combined with the above issue I tend to now `git fetch` rather than ever `jj git fetch`, avoiding the two problems, and just push with `jj`.

Other than that I'm loving the tool.

Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

Edit: worked a treat, thank you so much.

JJ used to use libgit2 for fetches, but it now can shell out to the git binary instead: https://github.com/jj-vcs/jj/pull/5228 (which will be the default in the future)

So far, I enjoy it a lot. Previously I would have a bunch of 'wip', 'fix typo' commits, but my commit history got much cleaner with jj. It's very easy to jump to old changes and apply fixes right in the place they belong. All changes + tests are now committed as one unit. I would never bother to do it in git, but because it's so easy now, I do it all the time.

Also, the possibility to add a description/message at any time, not only when you "commit" something at the end, is super useful. I use it as some kind of TODO list. Basically, I create a bunch of empty commits with a message and then just start from the first and work my way through all of them with `jj next --edit`.

If you have some extra time and would like to try out something new, I would very much recommend it.