jj tug
39 points by indigo
39 points by indigo
Nice. The ease in which you can write your own jj primitives is perhaps undersold by their official docs. Aside from what this article does, as aliases atop built-in commands, you can also shell out to your favourite scripting language... I wrote a jj move command to move filesets across revisions a little while back (alongside wrappers to tweak jj split and jj squash accordingly) and it's become the main way I interact with jujutsu ever since.
That's another thing with jujutsu I find interestingly, actually. There's no one way to use it! The tutorial discusses this a little bit with the "squash workflow" vs. the "edit workflow", but I think there's a variety of different and more fine-grained distinctions than this, and I'd be really interested to see them all. Especially with support for explicit tracking now! (Which isn't my workflow, but may be appreciated by others.)
Especially with support for explicit staging now
What do you mean with this? I thought the lack of a staging area was a defining feature of jujutsu, as opposed to git.
Yes, it is. I should have said explicit tracking. The snapshot.auto-track setting can take arbitrary path patterns now, including matching nothing, with which you have to explicitly track/untrack files with jj file.
I too am not following this, but admittedly I'm a few versions behind with my local jj for reasons (haven't had the spoons to tackle updating my Nix flake which is responsible for providing it)
As I improve the docs in the future, this is something I want to figure out how to share without being overwhelming. Input welcome, if you or anyone else has ideas about this.
workflow
Indeed, I just split everything and keep random junk in the working copy which will never get bookmarked.
Interesting because it feels like split is pretty weak UX especially compared to git add -p
I guess you don’t change the same file for multiple features?
Interactive split/commit is better than git add -p as jj gives you a proper TUI where you can go back and forth and not be on an unforgiving linear path of questions :)
I don’t get it, if you have multiple bookmarks between it and the last pushed commit won’t they all move? That seems dangerous and potentially error prone. I wonder if that’s why it hasn’t been upstreamed?
The function heads(x) removes all revs in x that are ancestors of other revs in x, so only the last bookmark will move