Allow topic branches that are dependent on multiple topic branches

[epage]

Discussed in https://github.com/gitext-rs/git-stack/discussions/223

^{Originally posted by **1tgr** March 24, 2022} Can I use git-stack to achieve this: ``` * bf02041 - (4 seconds ago) wip - implement feature 3 * 7709143 - (14 seconds ago) Merge branches 'feature-1' and 'feature-2' into feature-3 |\ | * 02ce6b4 - (40 seconds ago) wip - implement feature 2 * | c96a6fb - (49 seconds ago) wip - implement feature 1 |/ * 9595644 - (78 seconds ago) Initial commit (master) ``` That is: - Two independent feature branches based on master - A third feature branch based on the first two The idea is that the feature-1 and feature-2 branches don't rely on one another and will be reviewed and merged to master separately, and feature-2 shouldn't contain feature-1's commit or vice versa. But feature-3 does rely on both, and feature-3 should not be merged to master until both feature-1 and feature-2 have been merged. It looks like git-stack understands the merge commit (7709143 in the example above), but `git stack --rebase` appears to force a linear history with feature-2 stacked on top of feature-1.

[epage]

My comment on the discussion:

git-stack has tried to discourage merge commits in topic branches to encourage a cleaner history (ie rebase on top of master rather than merge). That combined with being able to ignore merge-commits for topic branches into master was able to simplify a lot of logic.

However, I hadn't considered temporary merge-commits for topic branches that would never make it back to master. I've run into this problem and found okay-ish one off solutions but supporting this natively would be better.

Going to go ahead and move this discussion to a feature request though I don't expect we'll have this implemented any time soon:

• We'll need write a new stack renderer that handles merge-commits (already want to do this for a git reftree idea I have for a graphical reflog)
• We'll need to update our internal data structure to handle merge-commits (already been thinking we'll need this for better handling of master)
• We'll need to update our algorithms to safely handle this
• We'll need to update our rebase code to preserve the shape of the graph both for regular rebases and for when we detect one of the base branches has been merged (and automatically remove the merge-commit when its not needed)