Post

jj is cool, but the base CLI seems more like a "workflow development kit" than an actual workflow people use. it is great for this - it exposes very powerful primitives! I just don't see it becoming the industry standard without more established bright line workflows

primitives like changes as documents, automatic rebasing, good options for manual rebasing, conflict management. all good stuff, and I will continue using it.

0 reposts2 likes

this is based on my limited experience using it for a classic GitHub pull request workflow with named bookmarks, so ymmv. please tell me what I'm missing / cool stuff that will change my experience with it!

- Create tracked bookmark in one command - Commit and update bookmark - Rebase children of updated bookmark (maintain my cthulu merge commit) Basically I want bookmarks to act more like a bundle of changes. Granted, I'm coming at this with git brain

definitely git(hub) brain :) at fb barely anyone uses bookmarks for anything, it's a weird git(hub) affectation that (like most of it) barely engages with any prior art

maybe another way of saying this is: I want a change whose parents are bookmarks, which themselves act like a change with many sub-changes?

What's weird is it feels so *close* to working well. If you set the bookmark to an empty change at the end of a branch, and you could do something like `jj new --before bookmark-name`, cthulu workflow works automatically But `jj git push` refuses to push the bookmark pointing at an empty change

`jj next` feels like mercurial and makes it much easier to tinker/amend a chain of commits as they're reviewed need I say more about `jj undo`

You're welcome! Fig at Google (a mercurial wrapper around Piper) really changed how I think about VCS and chains of commits. `hg evolve` and everything around it (like prev/next) is just...so much better than fixup commits and interactive rebase