github / github/gh-stack

Stack should be merged when merge commit is already pushed

オープン
#457 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Go
スター
1.5k
フォーク
70
平均マージ
1日 8時間
マージ済み PR(30日)
7

説明

## 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#1` is closed, because it's base is `main`, and GitHub automatically closes already merged PRs.
- `PR#2` and `PR#3` are **NOT closed**, because their bases aren't `main` (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

1. These PRs are shown as "open PRs" while they are already merged.
2. This will help 3rd-party integrations -- e.g. [bors](https://bors.tech/index.html) 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.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

既存の `gh stack sync` エントリポイントと、stacked PRs がマージ済みかどうかを判定するロジックを追跡します。ここで説明されている手動で push された merge commit のシナリオと、base の扱いを比較します。完了条件は、stack の base にそれらの変更が含まれている場合に、stack 内のすべての PR がマージ済みかつクローズ済みとして認識されることです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
git, github, go
領域
cli, devtools
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
58/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。