Stacking should handle rebases performed outside of gh stack
- 主要語言
- Go
- 星號
- 1.5k
- 分支
- 70
- 平均合併
- 1 天 8 小時
- 30 天內合併 PR
- 7
描述
Let's say I have
```
trunk: AA1
branch1: BB1
branch2: CC1
```
The stack JSON will look something like this
```
{
"schemaVersion": 1,
"stacks": [{
"trunk": {
"branch": "master",
"head": "AA1"
},
"branches": [{
"branch": "branch1",
"head": "BB1",
"base": "AA1",
"pullRequest": {
// ...
}
}, {
"branch": "branch2",
"head": "CC1",
"base": "BB1",
"pullRequest": {
// ..
}
}
]
}
]
}
```
If I now perform an interactive rebase (**outside of gh stack**) - e.g. to _remove_ the head commit from branch1, or if I do something like `git reset HEAD^1 --hard` **from a branch1 checkout**, the stack has no knowledge of what has happened.
If I view the stack, there's now one fewer commit on branch1 (as expected) **but one extra commit on branch2**. I'd like / expect that commit to have been removed entirely from the stack.
貢獻指南
研究方向
使用 trunk、branch1 和 branch2 重現該 stack,然後從 branch1 的 checkout 執行 rebase 或執行 `git reset HEAD^1 --hard`,並檢查產生的 stack 檢視畫面和 JSON。追蹤 gh stack 如何偵測分支基底和提交變更;完成條件是,從上游分支移除的提交不會作為額外提交保留在衍生分支中。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- git, go
- 領域
- cli, developer-experience
- Issue 類型
- 缺陷
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 活躍度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100