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 .

[bmcdonnell-fb]

I agree this would be useful.

I'm developing a feature in my application right now where I have a temporary test commit that I'm alternately including or not including on one of my virtual branches in my GitButler workspace. Unfortunately GitButler apparently doesn't provide a convenient way to do this yet.

Prospective ways to address my current need:

• With the feature suggested here, a stacked virtual branch with my temporary testing commit, on top of my feature branch. I could alternately include or not include the stacked test branch in the workspace.
• With Support for reverting commits #2931, I could alternately revert the temporary commit, or drop the reversion. (Until I'm done, then either keep the reversion, or drop the original.)
• Idea: "unapplying"/"hiding" commits #11528

[bmcdonnell-fb]

I think a good place for this in the UI would be adjacent to "Delete" in the branch context menu. Very similar conceptually. On the top branch in a stack, both would remove the branch from the GitButler workspace - just one would actually delete the branch, and the other doesn't.

I'm not sure yet about what if it's not the top branch in a stack...

[bmcdonnell-fb]

Actually, seems I misunderstood how "Delete" works, since it deleted the branch, but added my commits in the base branch. Is this expected and optimal behavior?

[Byron]

It doesn't actually delete commits - these are still part of the commit graph and if reachable through other branches, they will show up.
Deleting a branch only deletes the branch, and I think anything else would need another name with enough warnings to indicate that this will purge commits from history (or something), I didn't think how this would look like (if it's even what you are thinking about).

[bmcdonnell-fb]

"Rename" seems pretty self-explanatory; i.e. what else could it apply to but the branch?

But the context for "Delete" (i.e. that it operates on a branch, not a commit) seems only implied by its neighbor and grouping (with Rename). Might it be helpful to make this say "Delete branch" instead?

Also, I think a follow-up prompt might be desirable? Giving the option of whether to absorb the commits into the base branch (Yes/No/Cancel).

[foxfirecodes]

problem

im finding myself wanting to unapply a portion of a stacked branch quite often recently. my two use cases are:

1. i build a thing, then i stack a temporary branch on top of it to add debug/instrumentation code on top of the thing, and then i want to be able to stash that temp branch without fully deleting -- usually bc i debug via temporary UI and i dont want to keep seeing that UI but i do still want to have the changes being debugged to be applied to my workspace

2. i have a series of features in a stack, and then realize that one of those features is not going to be shipped for quite some time if at all. i dont want the work to go away, i could just reorder it to be at the top of the stack but then i still have to rebase and deal with conflicts in perpetuity

in both cases it would be incredibly helpful to be able to pop a branch out of the stack (even if that would result in conflicts) while retaining the correlation to the stack, so i can then later reapply that branch to the same stack (again, even if that would result in conflicts) (or if the stack no longer exists, it would be the same as just regularly applying a branch to the workspace)

workaround

i tried uncommitting the changes and then using the "Stash in Branch" functionality, but unfortunately that doesnt seem to be able to stash changes that are dependent on earlier changes in the stack -- it stashed everything except those dependent files. which kinda makes sense, but makes it unusable as a solution to my problem

for those stumbling upon this, its jank but there is a workaround:

stashing changes from the top of the stack

to save:

• uncommit the changes
• git stash [-u to include untracked changes]

to restore:

• git stash pop
• commit your changes to the old now-empty branch if you kept it or to a new branch at the top of the stack

stashing changes from the middle of a stack

to save:

• go into edit mode on the commit you want to stash
• git reset HEAD~1 -- i was concerned this would break things but edit mode seems to handle this gracefully
• git stash [-u to include untracked changes]
• exit edit mode -- the commit will be gone since you reset it
• deal with conflicts

to restore:

• create an empty commit in the stack where you want to apply the changes
• go into edit mode on the commit
• git stash pop
• exit edit mode
• deal with conflicts

both of these only really work well if you're using a single commit per branch as i do (im an amend-er :3), but if you dont care about preserving git history you can always just squash the commits of the branch in question and then follow these steps.

implementation

it seems like the trickiest parts of implementing a feature like this would be tracking the correlation between an unapplied branch and the rest of the stack, and the UX of reapplying. under the hood this feels like it borders on/steps into non linear graph territory, because if you unapply a branch from the middle of the stack, you now have one graph path that goes from the base branch to the unapplied branch(es), and then one graph path that goes from the base branch to the rest of the applied stack.

that being said, it sounds less complex than trying to support applied non linear graphs to the workspace (which id love, but i digress) because the workspace would still only ever have linear stacks applied.

under the hood, the actual git logic for doing this feels in my mind quite simple. if i have A -> B -> C -> D, im imagining this:

• if i want to unapply B & C and leave A -> D, you just leave the git history of B & C intact so they're still stacked on A, and then rebase D directly onto A, dropping all the commits from B & C
• if i want to re-apply B & C in between A & D, you first rebase B & C onto A (in case A has changed since unapplying), then you rebase D onto C

so the main trickiness is keeping track of the relationships between A to B & C to D, and the boundaries of branches so you know what commits to drop when rebasing. there's also some open UX questions of "what if i have created/reordered branches since unapplying", in which case i think you'd need some kind of interactive picker to decide where you slot the branches back in. but the actual git operations would just be about rebasing and dropping the right commits.

and all of this is with the assumption that conflicts might result from these operations and should be non-fatal to the operation, just like the behavior of existing operations like reorder, sync, edit mode, etc.

path forward

given this is a feature i am pretty passionate about as it is something id use frequently in my daily workflow, id love to hear thoughts on whether this would be desirable functionality! unless this is absolutely not something the team is open to, then when i have the time im going to open an issue with an actual RFC grounded in implementation. with the full expectation that i would do the implementation work if the team signs off on it, im sure this isnt exactly trivial to build and that yall are busy af lol.

to anyone else in this discussion, id love to hear if what ive proposed above would actually address your need! if not id love any feedback on what would work better for your situations

[Byron]

Thanks a lot for the research.

I was only ever thinking about not merging A stack from the top so that there is never an issue with conflicts inside of the stack. For instance, A->B with A being the top could merge the tree of B while putting A into the merge-commit, and GitButler keeps track of this.

But hiding arbitrary parts of the stack, which is what I understand, while dealing with conflicts somehow, is beyond me 😅. That doesn't mean much though, maybe @Caleb-T-Owens or @jonathantanmy2 have thoughts this.