jujutsu 0.45.0
65 points by olex
65 points by olex
Jj releases are really getting boring... Lots of polish and small things that make live easier, but very few things to get excited about.
I love that :-) Shows how far they have come and how stable the thing got in the meantime.
Do you have anything on your wishlist that you would find exciting?
I use jj workspaces extensively, to be able to let various things work on trees in parallel. jj workspaces and Git colocation are not in a great place. The non-default jj workspaces don't get a .git which ~breaks a variety of tools and scenarios, including some around Nix.
I think this is non-trivial and I'm told Caleb is working on it, but it's a pretty decent thorn in my side: https://github.com/jj-vcs/jj/issues?q=is%3Apr+is%3Aopen+author%3Acalebdw
Yes, literally getting bit by this yesterday when using workspaces and the tooling expects to be able to run some random git hash fetching on deploy.
Colocation of workspaces with git worktrees is my personal most-needed feature.
Unfortunately, a lot of tooling is git-aware, and most of it works fine with the default workspace, but breaks as soon as you're in a side workspace.
I'm not the OP but... hook support is my big dream.
The pre-commit hook isn't a great fit for jj because of Always Be Committing, but we think pre-push solves the same use cases. You can achieve something like that today with jj run:
[aliases]
'push' = ["util", "exec", "--", "bash", "-c", '''
set -e
branch="$1"
jj run -r "trunk()..$branch" -- my-lint-command
jj git push -b "$branch"
''', "jj-push"]
It's not the most ergonomic thing, but is this approximately what you want to do with hooks?
pre-push is in fact where I'm looking; pre-commit is obviously a bad fit -- as you say -- but getting something in the push path, either per-commit or per-bookmark, would be fantastic; I have all kinds of pre-commit workflows that my git-using compatriots benefit from that I'd love to be able to apply from jj, even if at a different time.
Submodules are still not supported, right?
I'd like to practice Jujutsu before using it at work. I mostly work with two personal repos, and one of the things I do more is work with one of them as a submodule of the other. So basically, for personal purposes, that's a bit of a showstopper.
(I should do a subtree integration in any of the modern fancy ways, but I'm lazy too.)
I'm crossing my fingers for copy-tracking. It's one of the areas where the usual "jj just works and git is unnecessarily tedious" is inverted. When files were moved, git rebase just works while jj rebase blows up with tedious conflicts.
Pushing tags would be pretty cool ngl
Something like commit hooks -- not easy with jj's model -- would be great.
But I am actually very happy with jj, and all the polish it gets:-)
jj converge
If hope this comes in handy when my branch is rebased in the remote and my local branch was updated.
I was hopeful, but it "didn't work" for me (or I don't understand it). I had some divergent commits from a rebase that I hadn't gotten around to cleaning up, and tried using jj converge, but it just led to a bunch of conflicted commits that weren't conflicted before. Thank goodness for jj undo, I'l figure it out later.
Edit:
Came back and figured it out partially. I've got a situation like this. We have a long-lived shared branch on an upstream repository, which we periodically rebase onto main. When we do this we tag the old head so it doesn't get pruned, since our downstream repo code references it by commit hash instead of branch (#justgothings).
When I performed this rebase the other day, tagging the old commit, now I've of course diverged the changes - some are tied to the old tagged commit, the others are tied to the new commit. So they're divergent, because they're both "visible" - one is part of a bookmark/branch, one is part of a chain of commits ending in a tag.
I could just leave these as divergent, because that's what they are. Or I could "solve" it by assigning new change ids to one of the sets of commits, to capture that they're different - but then I've sort of lost something by divorcing the changes from one another. In this case just to make my workflows easier I used jj metaedit to assign new change ids to one set of changes, and I could do this in the future by using jj duplicate instead of jj rebase. I don't love that though.
It's hard for me to completely understand how jj converge tried to fix this, even by staring at the jj op show -p output afterward. I wonder if this is just a case that it wasn't designed to address, because it's fundamentally ambiguous. I tried reading the design doc but I'm failing to grok how my case would map to it right now.
Converge looks great, but the reason I have divergent commits to converge in the first place is when I forget you can’t use workspaces in parallel. So I’m hoping when the worktree support comes out, I won’t need converge!
I've experienced divergent messes whenever I've been doing some automated work (like using jj-precommit which ends up doing "jj operations") but in some other branch absentmindedly fetching from upstream.
I try not to think too hard about why my stuff isn't always diverging wildly because the failure mode is so gnarly.
a dot release just released hours later https://github.com/jj-vcs/jj/releases/tag/v0.45.1
We weren't able to publish the 0.45.0 crates because we had the category "version-control" in Cargo.toml, and apparently that's no longer allowed on crates.io. This was a problem for this release because we created a new jj-core crate.
Rather than publish a different commit than the git tag, we chose to make a 0.45.1.
Would cargo publish --dry-run catch that, or is that done entirely on the remote side after uploading? (I'm unsure offhand if --dry-run includes any communication at all with the registry)
Good question! It doesn’t fail today, but the jj-core crate now exists so it’s possible it would fail if a new crate needed to be pushed.
I’ll have to remember to test that next time we add a crate.