how do i speed up rebases in PR stacks in graphite? after a portion of a PR stack lands, graphite takes it upon itself to rebase. but, on a longer stack, that rebase takes forever: about 1 minute per PR. this is way too long for my workflows that at the moment involve 30+ PR stacks. can i disable the autorebase/autorestack on server? similarly, the merge queue seems to be going commit by commit when the PRs are submitted for merge all at the same time (the green button at the top right saying "Merge 35 PRs"). in the activity pane of the merge queue, i see commits landing about 1 minute apart - as if each commit is landing separately. but, i believe we have turned on the setting that only runs CI on the group of PRs together in the merge queue.

Hi guys Is there any ways to precommit with

gt create

? I implemented the precommit and it only applies with git CLI, and my teammate uses gt create, and it still by pass Graphite seems has not any ways to deal it

how do i fix Graphite's CI optimization? i have the following output on a merge queue job:

odd to see "not skippable" and then the output is "skip"

i've got "merge when ready" set on a stack of PRs. why do they enter the merge queue one-by-one rather than together? i get that "merge when ready" can be eager, but i wish there was a way to say "wait until all of these are ready together" - it would reduce our merge queue CI load since we enabled batched PRs

how can i force a PR stack to be added to the merge queue where i know why CI is failing, but i cannot make everything green without the whole stack landing at once?

How can I refresh what teams I am on? For some reason Graphite is pinging me every time a specific team in our org is pinged. I was only on this team for about 2 minutes (I created it, added 3 other users and then removed myself)

when using graphite CI Optimizer, some of our CI runs are being deferred to run later, once downstack PRs are verified (that's great). however, i'm seeing upstack PRs marked "Ready to Merge" even though required CI runs have yet to happen (they are skipped/deferred by graphite). what's the appropriate way to integrate CI Optimizer to avoid these skips/deferrals being interpreted as success?

i have a very large stack of PRs. gt stops at 50. i'm not trying to post 50 PRs; i'm trying to post updates to the first 10 or so at the bottom of the stack. even though i used --no-stack, gt refuses to post updates. weirdly, it posts an update to the very first PR at the bottom of the stack but then fails. how do i work around this?

Hi, I need to manage billing settings for a Graphite org we run for a client (with Github enterprise). Since I'm not an admin on the Github org, I am also not an admin in the Graphite org? I think...

Hi, I'm increasingly having issue where Graphite CLI tells me my branch can't be restacked cleanly because of conflicts when I use the CLI checkout command like

gt get "bugfix/..." --unfrozen

or when I use

gt get

followed by

gt unfreeze

then

gt sync

fryej@GRP:~/Upload$ gt sync
:evergreen_tree: Fetching branches from remote...
main is up to date.

:arrows_counterclockwise: Syncing branches...
Branch bugfix/... is up to date with remote, but the current remote version was not pushed with Graphite.

:pancakes: Restacking branches...

WARNING: bugfix/... could not be restacked cleanly.

Please resolve conflicts in the current stack with gt restack.

If I check on app.graphite.com or via GitHub, there are no conflicts. One time

gt repo init --reset

and then checking out the branch normally via

git checkout

then

gt track

helped fix the isuse but that's not working for me now. Any idea what I'm doing wrong? Can this happen if another dev doesn't submit changes with graphite CLI?

Hey team, I was wondering why "Squash & Merge" is the recommended merge strategy over "rebase and merge". We're using the CI optimization and merge queue, so we're not actually merging anything really. We're trying to get to a situation where the commit message is helpful documentation of what happened and why (linked to Linear via footers and whatnot) following the conventional commit style so that it's easy to quickly parse and scan in the terminal or wherever; and the pull request description is information that's necessary for a reviewer. They're related, but not necessarily the same thing. With our current setup, all our lovely written commit messages are thrown away and the squashed commit lands in

main

with the PR description as the message. It includes all kinds of markdown, links to pictures, summaries from various AI bots doing reviews. It's terrible for scanning quickly via a

git log

. Any recommendation on how to achieve what we're going for? PR description for reviewers, commit message for description of the change? The Github "default" merge strategy achieves this I think, but because we're using the graphite merge queue and CI optimizations we can't use this 😞. Thanks in advance!

Is it possible to turn these notifications off?

Get this for the agent chat but I have a PRO account in cursor

Cursor Pro plan required
Cursor Cloud Agents is only available on paid Cursor Pro plans or above.

Is it possible to create a inbox filter that takes CI status into account? 🙂 I have a bunch of "Approved" things that still rejected by CI, so they are not "ready to go" 👀

How can I request all my bills for the last year?

Is there any way to have graphite create code tours automatically in the background instead of cold starting every time I open a new PR?

Is there a documented way to use graphite CLI in cursor cloud agents?

Is it possible to get a support Slack channel for our company? I work at Basic Capital

Could you please add shortcut for tour mode?

Facing some billing & subscription issues. Where can I reach out to for support?

how can a 2nd person/different author build a stack on top of another stack? It seems like when someone tries this, graphite will steal the top PR from the original stack and point to main, and it no longer tracks the original stack

Can I change the the "tone" of Tour Mode?

Hello 🙂 Just setup Graphite with my git repos and it can see all the PRs etc. I have (I think i have) also set it up to auto review the PRs and comment on them, but its just not doing it. I have followed the online guide any everything seems to be setup correctly - however I just get the spinning wheel on the comment feed and a larger accumulating amount of PRs that suggest they are being reviewed but are in fact not - any help appreciated.

how do i get from a Graphite review page to a Cursor Origin (codebases) review page? eg keyboard shortcut, url tweak, graphite chrome extension, etc seems like that's trending toward being the new version of the review page

How do I find out who mu company's rep is?

we have a long-lived development branch that is dearly paying the cost of non-grouped lands since graphite does not support more than one merge queue per repo. what can we do to avoid this? our preferred solution is to have the same merge queue policy (grouped PR merges) as our main queue

I can't seem to get the Graphite VSCode extension to authenticate on my mac I click the yellow triangle and it directs me to app.graphite.com/settings/cli to authenticate with a unique token I run the

gt auth

command on the VSCode terminal and it says i'm authenticated, but the extensions still doesn't show as authenticated

Hi! For repos with a ruleset that requires 1+ reviews before merging, Graphite does not seem to check who can bypass. The ruleset allows myself to bypass and merge, which is evident in github itself. But the merge button in Graphite says “Not ready to merge” with a “This PR needs more approvals” tooltip. In an older repo we still have the legacy settings, and in this case I am allowed to merge from Graphite, even though PRs require 1+ reviews. Am I missing some setting?

Is there some way to see whether or not something is in the merge queue from inbox view?