CLI: hiding the top of a stack leaves those branches stale after editing lower commits

Version

but 0.22.3

Operating System

macOS (Apple Silicon)

Distribution Method

CLI

Describe the issue

I wanted to review the bottom two branches of a four-branch stack on their own, so I hid the top two. but unapply always takes the whole stack, so I ran but unapply <top> and then but apply <second-from-bottom>, which brought back that branch and the one below it. That part works nicely.

The trouble starts when I edit the lower branches while the top ones are hidden. GitButler only rebases applied branches, so the hidden ones keep pointing at the old versions of the lower commits. but apply <top> then applies those stale copies as a parallel stack, so I can't simply reapply, fix and hide again.

How to reproduce

1. Create a stack: a ← b ← c ← d.
2. but unapply d, then but apply b (only a and b are applied).
3. Amend or reword a commit in b.
4. but apply d would apply d's history, which still contains the old b commits, as a separate stack. I didn't run it to avoid the duplicates.

What I did instead

1. but pick <c and d commits, oldest first> --above b, which created new branches on top of the current b.
2. Resolved the conflicts.
3. Tried to give the new branches the old names. but reword <branch> -m <name> refuses ("A branch named '…' exists but is not applied"), and but branch delete can't find unapplied branches, so I ran git branch -D on the stale refs and then renamed.

This worked, but it took a native git command, and it's easy to get into this state without noticing. For now I reapply the whole stack before editing anything below a hidden branch.

Questions

• Is there a better CLI path for this? The desktop "stacked apply" (#14919) sounds close, but I couldn't find a CLI equivalent.
• Could but apply (or a flag) rebase a stale unapplied branch onto the current version of the stack it came from?
• Could but branch delete support unapplied local branches? Since #15213 it seems to only see applied ones.