Merge instead of rebase for restacking

[vvanirudh]

Thanks for the wonderful tool! We have had a great time using it so far.

Currently, we primarily use a merge-based workflow, i.e. if there are any changes down the stack, then rather than rebasing branches upstack, we would like to merge the downstack into upstack to get these changes.

Is there a way to configure git-spice to use merges instead of rebases when restacking?

[abhinav]

I'd like to understand the motivations more, please.

There's nothing stopping PRs from being merged into the trunk with merge commits. Only the in-flight branches are rebased to get a linear pre-merge history.
If in-flight branches used merges instead of rebases, they would constantly introduce a large number of "merge feat1 into feat2", "merge main into feat1" commits before things can merged back into trunk.

So could you elaborate on the reasoning here a bit more?

[vvanirudh]

That's a good question.

Our development cycle (especially during pilots and demos) typically works with a test branch that has a bunch of PRs merged into it and some of its own changes as commits. At the end of the demo/pilot, we merge each of the PRs that were merged into the test branch into main. After each such merge, when rebasing the test branch onto main, we receive a ton of rebase conflicts as the original commits might have been changed slightly (or the ordering changed etc). In such cases, merging works much better and is easier to resolve conflicts.

Although this might seem like a very unique case, it happens quite often in our development cycle that it leaves us desiring a merge based workflow that allows us to still have branch stacks.