Replies: 1 comment
-
|
In our company, the current behavior is preferred, no matter where I am, after merging, if anything's on main branch, we gotta rebase, (we have linear history requirement), and the worst part is, we're not on the waitlist yet, so I'm using the regular PRs with gh stack, which means every PR merge, I gh stack rebase && gh stack push. Instead of changing defaults, I think it should be a config that you can set globally 🙂 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have made my first real stack of 4 PRs recently and wanted to mention some missing pieces in the API that result in wasted time for me. I might just be missing something here but hoping that there is at least a way to do this properly or that it is on the radar.
Essentially the scenario here is that my 4 PR stack was in code review and 3 out of 4 PRs received some comments which I addressed with a follow up commit on each branch. This worked really well for the bottom PR. I basically did this:
This worked really well and pushed up my bottom PR with the feedback addressed, and updated the 3 PRs on top as well, great!
the 2nd PR had no feedback so I went to the third one and addressed its feedback.
Meanwhile, CI has already started processing the PRs again, our CI takes a long time, upwards of 50 mins before a PR becomes mergeable.
Upon fixing the code review comments in PR 3 of 4, I wanted to use the wonderful
gh stack rebasebut this had the effect of automatically pulling the main branch and rebasing all 4 PRs, so all the time CI was chugging along was lost and PR 1 is delayed from being merged.I guess there is
gh stack rebase --upstackwhich I just discovered exists, but it's not clear if I'd need to also run that asgh stack rebase --upstack --no-trunkto avoid getting PR's 3 and 4 somehow on a new trunk and diverged from PRs 1 and 2.I guess essentially this is a comment on intuitive defaults. It'd be really nice if gh stack rebase could detect if you were mid-stack and then defaulted to only doing behavior of
--upstack --no-trunk. I can't imagine a scenario where I am working on a mid-stack PR and then want to rebase PRs downstack, it's always the opposite.Beta Was this translation helpful? Give feedback.
All reactions