Allow unapplying of part of a stacked branch

[lmself95]

Stacked branches are in theory a really useful way for me to work on a large piece of work that needs to be broken into several PRs.

However, the way we merge PR chains in our organisation is bottom up, i.e. each one is merged separately into master rather than top-down where each is merged down into a final large PR that can be merged into master. This means we can lower the risk of rollback by testing each individual change one at a time, and make it easier to identify the cause of issues compared to trying to unpick a massive PR.

However, this creates a need to be able to test each branch independently of anything further up the chain. If I have

|- Feature 4
|- Feature 3
|- Feature 2
|- Feature 1

And I need to make a change to Feature 2, I want to be able to unapply just Features 3 and 4, as this will ensure that the correct functionality isn't predicated on something higher up that won't be merged until later.

What would be great is if there was a function in the Workspace, under the menu for each branch, which would 'unapply' any branches stacked above that branch and grey them out in Gitbutler.

|- Feature 4
|- Feature 3
|- Feature 2
|- Feature 1

Could be called 'Unapply branches above' or some such thing. You could then have a button on that branch to reapply the ones above it.

As it stands the workaround is basically not to use GitButler if my change is sufficiently complex that I know it will need a stacked PR chain, or to make my changes in GitButler and then checkout the branch outside of GB to test it,

[Byron]

Thanks so much for sharing, I also think this is useful and it's actually quite straightforward to implement.

There already is a notion of creating the workspace merge commit by merging not the tip of the stack, but any commit further down.

gitbutler/crates/but-core/src/ref_metadata.rs

Lines 465 to 473 in 82ec107

	MergeFrom {
	/// If `None`, the tree of the stack isn't observable at all in the workspace tree, even though it's stack tip
	/// is a parent of the workspace commit. This is useful to 'mute' stacks, without losing track of them.
	///
	/// If `Some(commit_id)`, the `commit_id^{tree}` is merged into the workspace tree, while the tip of the stack
	/// is a parent of the workspace. `commit_id` is assumed to be in the stack, and observable by the user.
	/// This is useful to view a different stack segment, not only the tip/top-most commit.
	commit_id: Option<gix::ObjectId>,
	},

This would have the desired effect of merging a different tree while officially claiming that the tip is merged. The GUI would need special support for visualising this correctly. CC @OliverJAsh .