Stack should be merged when merge commit is already pushed
还没有人认领这个 Issue。
评估
调研方向
追踪现有的 gh stack sync 入口点，以及用于确定堆叠 PR 是否已合并的逻辑。将其对 base 的处理与此处描述的手动推送 merge commit 场景进行比较。当 stack 的 base 包含所有 PR 的更改时，如果 stack 中的所有 PR 都能被识别为已合并并已关闭，则表示完成。
由索引模型根据 Issue 内容生成。
描述
Reproduce step
Let's say you have this stacked PRs.
main <- PR#1 <- PR#2 <- PR#3
Now, you manually create merge commit and push it to the main.
prv_main <- PR#1 <- PR#2 <- PR#3
\---------------------+-------new_main
Current Behavior
PR#1is closed, because it's base ismain, and GitHub automatically closes already merged PRs.PR#2andPR#3are NOT closed, because their bases aren'tmain(they point to previous PR's tip), so they still have diff remaining, and PR isn't closed.
Expected Behavior
- All PRs should be closed.
How to fix this
Stacked PR should check it's mergeability against the whole stack's base (e.g. main in this case).
Basically the whole point of stacked PR is that "your PR is pointing to another PR, but they are treated as pointing to base".
Why this should be fixed
- These PRs are shown as "open PRs" while they are already merged.
- This will help 3rd-party integrations -- e.g. bors manually creates octopus merge commit of PRs and push it to main.
I know that you can manually gh stack sync, but I think this should be done automatically.
- 主要语言
- Go
- 星标
- 1.5k
- 派生
- 73
- 平均合并
- 1 天 8 小时
- 30 天内合并 PR
- 7
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
github/gh-stack 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
-
难度 1/5 1 小时以内 新手友好度 92/100
-
feature request topic: cli - general
难度 2/5 1-3 小时 新手友好度 68/100
-
feature request topic: auto-merge
难度 2/5 1-3 小时 新手友好度 68/100
-
bug topic: docs
难度 1/5 1 小时以内 新手友好度 68/100
相似的 Issue
-
feature-request helm
难度 2/5 1-3 小时 新手友好度 68/100
gravitational/teleport#69785 ·
-
bug
难度 1/5 1 小时以内 新手友好度 92/100
-
难度 2/5 1-3 小时 新手友好度 84/100
-
难度 2/5 1-3 小时 新手友好度 88/100
crossplane/crossplane#7859 ·
-
难度 1/5 1 小时以内 新手友好度 90/100