Using jj & josh-filter together -- have any thoughts/reccomendations?

[kitlith]

This is half "hey look at this cool thing and the workflow I'm building around it" and half getting eyes to see if i've missed anything handy in jj to support this workflow.

I'm using josh (Just One Single History) to import, rewrite, and stitch together parts of a couple of upstream repositories, and jj to handle my changes that are built on top. I wrapped the parts that needed automation into a script, here: https://github.com/kitlith/Dummy.Quic/blob/workflow/update_remotes.sh The general idea looks like:

jj git fetch --remote dotnet -b main
josh-filter --update refs/heads/dotnet-subset-tmp dummy-not-filter --file "$filter_file" refs/remotes/dotnet/main
# repeat for msquic
jj rebase -s merge -d workflow -d dotnet-subset-tmp -d msquic-subset-tmp

In the actual script, I use bookmarks a lot. That's partially since josh-filter takes as input and output git refs, and creating a ref that looks like a branch/bookmark was the easiest way I found to make that visible to jj. (is there a better way to do this, maybe using symbolic refs?) Those probably don't need to persist like they currently do. workflow can remain, but the merge bookmark should probably be managed a different way, maybe like #7588 (comment), unless someone has another suggestion.

Anybody have any thoughts on a revset for jj log that would ignore the upstream changes? It's currently kinda unwieldy, seeing all the commits from upstream that I don't care about interspersed with my workflow changes that i do care about (maybe i'd be better off keeping my workflow changes after the merge, instead of before the merge? shrug)

This workflow is going to be an adventure for me, and I'd also be interested in hearing any thoughts on how good or bad it's going to be. (for instance, I think I can predict that this is not going to play to github's strengths as a git forge, given that the code I write on top of the merge commit is going to get rebased any time I update upstream.)

[kitlith]

Ah. I'm also totally going to need to customize the immutable revset. Fun.

[kitlith]

I guess customizing the immutable revset is kinda killing two birds with one stone.

What I've currently got is this:

revset-aliases."immutable_heads()" = "(present(merge)- ~ workflow::) | present(main@dotnet) | present(main@msquic)"

which only relies on being able to identify the merge commit (somehow) and the workflow branch.

[PhilipMetzger]

@thoughtpolice probably can give you the best answer since he uses it and wants something similar built into jj itself