Idea: Revset, only valid in jj bookmark move ---to '...', pointing to the bookmark being moved

[cormacrelf]

You can move many bookmarks at once with jj bookmark move. But you can't move them to different target revisions.

Let's say the --to revset is evaluated separately for each bookmark under consideration, and it had a revset available called bookmark_being_moved() (or whatever).

Then you could have a workflow like

jj new feature/a feature/b
jj new; jj commit -m 'new work for feature b branch'
# push it down
jj rebase -r @- -A feature/b

# given a revset alias to find the most recent merge commit in `::@ & mutable()`, left as an exercise to the reader
jj bookmark move \
    --from 'heads(::mostrecentmerge()- & bookmarks())' \
    --to 'heads(bookmark_being_moved()::mostrecentmerge()-)'

Then you would have

@  uwsxtpos
│  (empty) (no description set)
○    unrxkknt
├─╮  (empty) (no description set)
│ ○  qolnqnsu
│ │  another change to two.txt
│ ○  qnytltqn feature/b
│ │  two.txt
○ │  mqnuurox feature/a
├─╯  one.txt
◆  zzzzzzzz root()

automatically move up feature/b from qny to qol.

[yuja]

Some of the ideas in #4980 might help express this kind of operation.

That said, it wouldn't be uncommon to move bookmarks forward to certain points. If we can come up with a general query applicable to most scenarios, maybe we can add jj bookmark advance --from|--to or jj bookmark move --advance ...

[arxanas]

Is this a workflow you actually perform a lot? What's the use-case? How do you accomplish it right now?

I wonder if it might be best to keep the one-bookmark form and have users build on top of it somehow (either via existing templating + shell scripting mechanisms, or one of #3219, #3575, #3814), rather than expand the interfaces of the commands and DSLs.

For comparison: git-branchless offers a specific git sync command which is generally meant to bring local work up to date with the state of the remote. It's much more limited, but if it turns out that this workflow is primarily meant to "sync" local branches with their remote ones, and not general-purpose use, then we could also consider a dedicated command rather than a general mechanism.

[cormacrelf]

Yes. I am commonly working on 3-4 different branches under a merge commit, and moving commits from after the merge into one of the branches. I do it manually by calling jj b set. I want all the bookmarks to float upwards as I do this.

None of the auto advance bookmarks stuff helps because my @ revision is separate. An alternative would be e.g. a flag jj rebase --advance -A feature/b that advances the branch if it can, without requiring me to "switch to that branch" with @.

[arxanas]

I see, so not at all like a local/remote syncing workflow, but in order to enable a "mega-merge" workflow.

In your particular case, it sounds like you manually have to rebase commits into their constituent branches one at a time anyways, so it seems like you would still do O(branches) work even if you had a command that could move all the branches simultaneously, so it seems to me like you might benefit more from some affordance in jj rebase that would let you advance the branches.

A kind of workaround that's particularly suitable for the mega-merge workflow might be to have an empty commit at the end of each branch so that you can always do jj rebase --insert-before <branch> and have the commit end up on the correct branch. Then either you could push the branches as-is and remove the empty commit later, or always push the parent commit of your local branch to the remote branch. (The assumption is that you don't have stacked branches, or else some of the branches would have meaningless empty ancestor commits. It might be interesting in the long-term to explore the design space of "empty commits with associated branches" because jj today doesn't handle branches very well, but it does have a rich vocabulary for addressing commits.)