🎩 I wrote up some steps for how you can only run CI at the top of a stack This stops you from having to worry about making sure each intermediate PR passes CI – as long as the top PR passes, you're golden. A common situation where this is helpful is when you have unused functions that are used in later PRs – no more workarounds to get your compiler/linter to ignore the fact it's unused 🙂

Hey team 🙂 Is there a way to automate the closing of ticket with linear, when using CI optimization (since the PR is closed, not merged) ? We tried to leverage magic word but it's another thing to remember to add on every PR description. Any way to add it as template or something like this ? 🙂 Thank you

when I do

gt pr <branch name>

how do I get the graphite.dev URL without opening my browser? I have my own separate workflow and just want the URL from the CLI.

Hi! I'd like to set up an Inbox filter for "PRs that are in ready-to-merge status" - something like: • author is {me} • PR status is {Open & Ready To Merge} • Upstream branches are {all approved} What I'm really trying to do is have an Inbox section that is "here are the PRs that are ready-to-merge, because the PR is approved and its upstream branches are also approved/ready". See this PR at the top of the stack? I don't want it to show up in my "Ready to merge" filter, but there's not currently a way to configure an Inbox filter to do this. (Right?)

Hi! I need help with the Github Workflows, 90% of the time nothing runs, I get this: Checks in progress... 0 of 6 completed - 6 required checks It's very common when updating a PR deep down, the ones above don't trigger a run The cancel/rerun button won't do much The solution I currently have is to git push nothing then submit to trigger another workflow run, it's not ideal I would expect the cancel/rerun to work I tried triggering a workflow to rerun manually but Graphite doesn't get its status, cmd:

gh run rerun {prev_workflow_id}

hi team, question on merge queues. I see a PR queued but not merging, how can I fix this?

Hey when I

gt submit

: • I never want the "keep as draft"/"publish" dialog - please don't ask me to click! Make it a draft please! • after clicking "keep as draft" please don't ask me to click "go to top of stack" or "go to inbox" - I don't know who dreamed this up, but if I wanted to go to my inbox I can easily do that Dialog after dialog feels like a hellscape to me. I don't want to click once let alone twice! I'm sure you'll tell me there's a

gt submit

option to just submit as draft that avoids this (there better be!) but the default webapp behavior definitely should not be this!

How do I enable merge queue CI settings/optimization with rulesets? The modal mentions not being able to detect whether the settings are correct, but then doesn’t allow setting CI settings at all.

Is there a way to provide guidance for the AI used for creating PR / Stack Titles? For example can I always have it use conventional commits and add a linear task id based on the branch name?

Is there a way to completely turn off AI reviews/suggestions? I only see this setting which is already off but I would also like to disable this for non-draft PRs. Thank you!

Hi, is there a way to remove 'closed' PRs from the stack view?

Another question - please could someone point me to which settings page I can change these merge strategy options from?

What's the timeline on Jira integration?

Is there a way to get the parent of a given branch? Like

gt parent <some other branchname>

? Would really be useful to me I know

gt parent

gives the parent of the current branch, which is useful, but not what I'm asking for here

If I have a stack like this

main ── a ── b ── c  
              \    
               d  
                \    
                 e

(which I just made by accident), how should I change the parent of “d” to “main” so I split the one stack into this stack

main ── a ── b ── c

and this stack

main ── d ── e

hi! is there any possible workaround to have PRs marked as "merged" instead of "closed" while using "Fast forward merge"? i know you all must get this question all the time, but we have users on graphite and github, and it's driving us up a wall.

I'm running into an issue where graphite's

merge when ready

toggle creates a temporary commit to our main branch, which triggers our deploy job, but then the code is not available on the main branch if you pull main, meaning that if something breaks, you can't see what it is in git. The functionality going on is that graphite does a temp commit onto main, then waits for the deploy job, then actually merges it, retriggering the same deploy job (ideally). I ran into a case where a flaky synthetic that doesn't block deploy caused graphite to never merge the code, and I found the still open PR on github. Is there anyway to disable this "temp merge commit" behavior in graphite? Are there any unique properties graphite uses I can use to block CI from picking up the deploy job? Do other people have this issue of graphite causing drift between what's deployed and what's recorded in git?

When I am writing a stack, I frequently use `gt up`/`gt down`. Today for the first time I checked out a branch to review, and I noticed that `gt up`/`gt down` do NOT move up and down a stack that someone else has written/stacked/submitted. I tried

gt get

,

gt sync

to try to "pull" the stacking metadata. Is there any way to locally inherit remote stacking order? Thank you!

I can't see all of the repos it my Github account. I can't see any config differences in the one I wish to connect to compared to one I have connected to

Does Graphite reviewer have PR title/description context access? I'd like to add some automated checks regarding title conventions and descriptions but the rule I added doesn't appear to be working.

I mistakenly kept the setting on in GitHub to require merge request approval after rebase. This breaks the stack merge because it requires more approval. I changed the setting in Github but it does not change the behavious on graphite for this merge stack. How do I get this merged... its a stack of 21

How do I enable automatic PR reviews for any new PRs on a selected subset of repositories for my org? Context in 🧵

is there a way to see a diff of entire branch/layer against its immediate parent? works in raw shell, but not inside

gt aliases

git show "$(gt parent)".."$(git branch --show-current)"

Is there a way to opt-out of the "Suggested fix" feature? I don't find the suggestions helpful and I'm constantly dismissing them.

Hi 👋 curious about some discrepancies in Insights I'm observing. I see users who had previously been Graphite users who were decommissioned from the repo being excluded from historical data in the Insights user list. Based on my interpretation of the methodology here I wouldn't expect this. • Is this intentional? • Are their contributions still aggregated in overall stats or are they excluded there too? Thanks for any direction/ideas here!

How should I setup my GitHub actions CI requirements if I use CI optimization? I found that if I just skip required tests that are optimized away, then Graphite can merge multiple PRs at once, even those that didn't get all checks run. I'm now adding a final check which fails if CI optimization was triggered. Is this the correct approach?

hey all. we're having issues with github actions and graphite. we have sql migration that runs on prs on main that are closed. but only the bottom diff in a stack is triggering this. wondering if we should try triggering on push to main instead and if there are any other settings we should try?

Hey team 🙂 How to create filters for the PRs in graphite UI and share it with the whole org ? For now we only see a URL sharing 😄 Thank you!

hello -- i was on vacation and when i came back today, my graphite was no longer authorized to my team's graphite. when i tried to re-authorize, i'm getting "missing permissions" for the repositories under my org. i have been granted permissions to my org's repositories so i can't tell what the issue is. would appreciate some support here 🙏

hey all - we were wondering why Graphite needs these temporary draft PRs when using the parallel CI feature in the merge queue. Unfortunately the docs only explain the how but not the why. We were wondering if it would also work with just temporary branches to avoid the PR spam?