Why isn’t 7884 in my PR inbox?
# report-bugs
t
Why isn’t 7884 in my PR inbox?
✅ 1
p
(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using
gt feedback --with-debug-context <any message>
can you confirm the following on your end: 1. does the pr exist in your selected default repos? 2. are you an assigned reviewer ? 3. which inbox do you expect to see this PR in? 4. do you have any customer filtering applied?
t
1. Yes 2. No, I’m the author 3. One of the two in my screenshot 4. Not sure what this is
p
thanks tyler! i'll take a look into it
the
waiting for reviewers
filter shows that the parent branch has to be:
master
,
release/staging
,
release/qa
,
main
, or
develop
. look at the PR, it looks like the parent branch is pointing to
graphite-base/7884
. you can use
gt track
to re-set the parent
t
Oh interesting, nice find! Why didn’t this get restacked automatically when the downstack merged?
And is there a better way to filter for just the bottom of a stack? I don’t necessarily like maintaining a list of potential trunk branches
p
Why didn't it restack automatically? Before merging, Graphite retargets upstack PRs to a temporary branch to prevent GitHub from auto-closing them. Better way to filter for bottom of stack? Today the only branch-matching filter available in inbox sections is Base branch but we do have a feature request to filter for the bottom of the stack.
🙏 1
t
Before merging, Graphite retargets upstack PRs to a temporary branch to prevent GitHub from auto-closing them.
Got it — but shouldn’t it then move to trunk when it finishes? This wasn’t just a temporary state.
p
you're right. (its my 4th day at the company and getting a handle on all things stacking 🫠) ideally the PR should have been retargeted back to the trunk after the merge completed. im wondering if the post-merge rebase step that handles this didn't run or didn't complete successfully for your PR and if this was due to this incident that we had. it looks like the PR is showing up correctly for you now!
t
Yes, I manually restacked it, but I’d like to avoid such situations in the future if possible
p
i totally understand since you shouldn't be doing it manually! i'll chat with the team about this.
🙏 1