How do I configure jj to treat my open merge/pull requests to be mutable without ruining the output of jj log? (I think I'm holding this at least a little wrong)

[badp]

My git workflow involves accumulating and refining changes into a topic branch with a lot of git add -ps, git commit --fixups, git rebase -i --autostash --autosquashes and git push -f HEAD:refs/heads/topic-branch-name-here (I often don't know what I'm working on exactly until after I'm done with it, so I tend to prototype on top of trunk a lot). Lather, rinse, repeat, until the topic branch is perfect, or at least good enough to be accepted and merged into branch by whatever git forge.

Jujutsu seems to be really compatible with my workflow, so I've been giving it a try. jj split in particular is super attractive. Running jj new before git push is at least a little weird, but I can deal with it. So far, so good.

However, under default configuration, the moment I push my changes to source control, jj immediately considers my work to be "shared," and thus "immutable," even though it still needs to pass CI, review, be rebased, etc. a bunch.

If I don't want to be typing in a lot of --ignore-immutable's, I'd have to teach jj that topic branches are mutable.

"Sure," I say, and type something along the lines of jj config set --repo 'revset-aliases."immutable_heads()"' "root()..main@origin". Except now every single one of my coworker's topic branches are now mutable (something honestly I could live with...); distressingly, this also means that approximately all of them now show up in jj log!

I thought jj log showed all mutable commits, but jj config get revsets.log tells me reality is a bit more complex than that, so I'm not sure I'm equipped to figure out a better revset. So, for now, I'm instead settling for jj config set --repo 'revset-aliases."immutable_heads()"' "root()..main@origin | ~mine()" as an approximation of what I want: treat just other people's commits as immutable, and then I get to hide topic branches that I've given up on with jj abandon.

However, there doesn't seem to be an obvious way to un-abandon work? What do I do if a topic branch I was working on becomes relevant again? Do I have a better alternative here than declaring jj-bankruptcy and run mv .jj .jjj && jj git init --colocate?

I'm glad I've figured out as much as I have on my own, but I think I might be zooming into a local optimum that's a little too... unidiomatic and inergonomic. So I'm welcoming feedback on what I could do to let me workflow be jj-ier, and/or how could I make jj be bp-ier.

[flowerysong]

However, under default configuration, the moment I push my changes to source control, jj immediately considers my work to be "shared," and thus "immutable," even though it still needs to pass CI, review, be rebased, etc. a bunch.

Only if you're not tracking the remote branch. Tracked remote branches default to mutable.

[jennings]

The reason you’re running into this is you’re creating a remote bookmark (branch) without a corresponding local bookmark (with git push origin HEAD:branch-name).

The usual workflow is to create a local bookmark and push it. When you do, jj will track the remote bookmark it just created:

jj bookmark create my-feature -r @- 
jj git push -b my-feature --allow-new

To begin tracking an existing remote bookmark, use: jj bookmark track my-feature@origin

[flowerysong]

As for hiding stale branches from your default log view instead of abandoning them, you can add a text tag to the description that makes it easy to filter them out, or I've seen an example (though I don't recall precisely where) of just doing it based on age.

vereveel-zeke ~/git/jj_scratchpad $ jj log
@  uosstltv Paul Arthur 2025-08-06 23:36:17 7fdb8907
│  (empty) (no description set)
│ ○  lomxqkxv Paul Arthur 2025-08-06 23:35:49 0c76c539
├─╯  in flight
│ ○  prvskkst Paul Arthur 2025-08-06 23:35:02 4cdaf4ba
│ │  archived: branch 1
│ ○  rpxonsxw Paul Arthur 2025-08-06 23:34:47 3c8176e7
├─╯  change
│ ○  nkvomnkt Paul Arthur 2025-07-19 06:26:00 ca1f01fe
├─╯  foo
○  lpouqkss Paul Arthur 2025-07-06 13:21:18 b9627fe3
│  bar
○  mrlktkvt Paul Arthur 2025-07-06 13:20:01 adefd2cd
│  initial
◆  zzzzzzzz root() 00000000

vereveel-zeke ~/git/jj_scratchpad $ jj log -r 'present(@) | ancestors((immutable_heads() | description(glob:"archived:*")).., 2) | present(trunk())'
@  uosstltv Paul Arthur 2025-08-06 23:36:17 7fdb8907
│  (empty) (no description set)
│ ○  lomxqkxv Paul Arthur 2025-08-06 23:35:49 0c76c539
├─╯  in flight
│ ○  nkvomnkt Paul Arthur 2025-07-19 06:26:00 ca1f01fe
├─╯  foo
○  lpouqkss Paul Arthur 2025-07-06 13:21:18 b9627fe3
│  bar
~  (elided revisions)
◆  zzzzzzzz root() 00000000

[jennings]

To expand on that a bit: Abandoning is for commits you want to discard. It’s like deleting a branch in git: You can get those commits back if you use the op log (reflog in git), but it’s not really the intended way to work.

If you just don’t want to see the commits in log output, you want to write a revset that just selects the revisions you’re interested in.

If you want to hide old branches my default, there are revset functions for selecting by date. For example, to select only branches with mutable commits that have been edited in the last month:

ancestors(
  reachable(
    mine()
    & committer_date(after:”30 days ago”),
    mutable()
  ),
  2
)