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.

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!

0 reposts2 likes

- 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

yeah, companies invest in painting bright lines for you and integrating with their tools. github is a menace, but it /is/ the prior art now. the UX still needs to be excellent.

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

In short, I want `jj git push` to ignore trailing empty commits and push the parent instead. I would make this the recommended way to use named branch workflows with multiple commits in a PR Adding a change to a branch becomes `jj new -B branchname`

Like, if empty changes are The Way (or at least A Way), why does my workflow now involve managing a bunch of off-by-one errors?

`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