Replies: 2 comments
|
Absolutely +1 Our policy is to also not allow rebasing, as it modifies git history through force pushes, which are forbidden. Thus, we'd love to see "merge" as one of the strategies 🙏 |
|
#270 and #294 seem related. Another issue with force push (true generally in GitHub) is that it makes for a confusing experience for reviewers revisiting a PR in the stack after the author has run For a variety of reasons I would appreciate an option to manage a stack entirely with merge commits rather than destructive history operations. If you want to reorder PRs in the stack or insert or remove PRs not at the top, then destructive operations are inevitable, but in the normal course of pushing follow-ups to individual PRs and refreshing the stack from the base branch you should be permitted to use true merge. Whether the PRs are ultimately merged via true merge or squash would be a decision that could be deferred until then. |
Uh oh!
There was an error while loading. Please reload this page.
In our company, we loved the experience of the Github Stacks!
However, it seems that we won't be able to rely on them fully, as they only support cascading rebases, and our branching policy forbids using them.
Instead, we would love having possibility to perform "cascading merges", as if we'd click the "Update branch" button for each PR in the stack.
All reactions