Sometimes the CLI changes the base branch to

graphite-base/[n]

. When does this happen? It sometimes breaks

gt get

afterwards, because the CLI will error that the PR has not been created with Graphite. People are on the latest CLI version.

Hi, I really like using the VSCode extension. However, there is one area that is painful to use: the commit message input. Here's a list of what's not right: • if you leave the extension tab, the message is lost • if a pre-commit hook fails, the message is lost • if I type too fast, some characters are lost 😭 (hard to record though as it mainly happens when my CPU is busy) • it would be great if pressing the UP arrow would show the last entered message (like the default behavior for VSCode commit message input)

I am having the “`graphite-base` branch doesn’t exist” issues in GH CI, as previously discussed in https://graphite-community.slack.com/archives/C02DRNRA9RA/p1741801162679489?thread_ts=1737026419.655359&cid=C02DRNRA9RA. What is the current state of this? It sounded in that thread like there was a feature flag I could ask to be flipped in my org to make the problem go away? Is that still the case? What are the downsides of it? Ty!

https://app.graphite.dev/github/pr/CondorSoftware/condor/5718/Fix-forecast-ending-earlier-than-expected-for-an-edge-case is stuck “Waiting to merge…” indefinitely

Hello, I keep trying to enable Diamond on a repo, I click save, it refreshes to this... It's also not clear if I can just try it on an initial set of PRs to see if it tends to spam

It says Diamond left 1 comment when she actually left three

Hi team, as of a recent Graphite update a few weeks ago as soon as I enable the Graphite VS Code (/Cursor) extension there is an avalanche of Git processes getting spawned constantly - I’ve tried both the homebrew and NPM variants of the CLI with the same result for each although I could swear with the homebrew one it was worse the fans on my M4 Max mbp would constantly spin up

gt --version
(node:96999) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
1.6.1

Extension version 0.6.1

Hi team, just found that this description area recently got width auto expanded to full width in edit mode only. This is really annoying because it is ONLY full width in edit mode, causing a UI flickering.

Code blocks with

plain

should not do any code highlighting but do. https://app.graphite.dev/github/pr/spockframework/spock/2157/Make-the-preprocessing-tasks-for-workflow-files-cacheable#discussion-IC[…]OABG6hs6pZ9k1 is displayed in GT as

Graphite should not be notifying me about comments mentioning me from

@graphite-app

I can’t leave any comments on this PR. Refresh does not help.

can someone from graphite help me with a billing question? Diamond got turned on for us automatically and pushed our bill above our budget and failed the payment. I don't believe it was done by our members.

I recently enabled Merge Queue to try to help with merging my PR. I've restacked it about 20 times against trunk, and it has no merge conflicts. It's been kicked out of the Merge Queue twice due to "Merge Conflicts". When it gets kicked out, it gets into a perpetual state where it's waiting for Tests to complete but there is no GH Action that is running the tests. I've tried refreshing (rerunning the work) and then it infinite loops into a "Cancelling..." I ended up merging it on GitHub by bypassing all the rules. What other debugging information can I gather?

👋 hi, we've been noticing some CI issues whenever we reorder or move PRs around in stacks, i.e. the 'New Parent' update - a common case is that a linter or other tool wants to get the diff between branches, and fails to checkout the parent branch with a message like

fatal: couldn't find remote ref graphite-base/{number}

Is there a suggestion for handling these cases? Syncing and pushing up a second time appears to resolve this as the branches will now be pointing to their correct parent, but it's kind of annoying to have to run CI twice whenever reordering

This message was deleted.

​*[Investigating]*​ Graphite - Database performance issues causing site slowdowns We are currently investigating this incident. ​*Affected:*​ Dashboard View incident button

​*[Monitoring]*​ Graphite - Database performance issues causing site slowdowns We implemented a fix and are currently monitoring the result. ​*Affected:*​ Dashboard View incident button

​*[Resolved]*​ Graphite - Database performance issues causing site slowdowns This incident has been resolved. ​*Affected:*​ Dashboard View incident button

hi team, we ran into a case where a pull request was ready & sent for code review three days ago, but on Graphite it didn't show up in any of reviewrs' needs review section. I clicked on the PR in graphite today (it remained in 'waiting for author' section incorrectly), and then the state refreshed. Is this a known issue? let me know what type of debugging info will be useful to you, if any!

I don't know if this is a bug or just user error somehow. I just recently set up GPG signing for my Git config, and when I am trying to create with Graphite, it is telling me that it cannot sign. I am not super familiar with Git so like I said could be user error. The specific error is: ``error: gpg failed to sign the data fatal: failed to write commit object ERROR: Command failed with error exit code 128:``

my web app has been in this state for quite a while now (not sure how long, I forget). My

Approved

and

Waiting for reviewers

sections in my Inbox just spin forever... they never load

Diamond code review keeps falsely reporting:

The

readlink -f

command is not available on macOS, which could cause this script to fail for macOS users. For better cross-platform compatibility, consider replacing this line with...

% which readlink

/usr/bin/readlink

Got a weird case where Diamond inserted a

+

at the beginning of a suggested fix, I assume it's something related to the way it's parsing diffs. Suggestion was correct but the diff injected that extra

+

which obviously doesn't compile. https://github.com/ethereum-optimism/optimism/pull/15664#discussion_r2072100885

I have selected some repos with some PRs but none of them is showing up in the application. It is not syncing, nothing. They all have recent prs, they're on my personal account, not an organization.

Good morning, it seems our graphite hit some issues, we reached what seems to be a limit of open PRs (a chain of about 50) and issues about sync-ing with GH occurred. try to close some of the PRs we got into a state that we cannot se any repo in graphite ... via the feedback link I've send more details as a bug report. I would appreciate some quick help here. I'm good if you nuke all metadata of the offending repo on the graphite side as we have a 'proper' up to date branch in GH. Thanks.

Seems like

gt restack

consistently hangs when encountering conflicts that require manual resolution. ctrl+c unsticks it without problems, and allows resolving the conflicts.

Graphite just totally lost my staged changes:

(main):zap: % gt c -m "commit mst"
Running post-checkout hooks


✓ All post-checkout hooks passed


Unable to setup environment for pre-commit hook run:
STDOUT:
STDERR:fatal: Unable to create '/Users/bmulholland/dev/…/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
Running post-checkout hooks

and then my changes are gone

Hello, my organization has been having this issue for some time. Sometimes, when adding a PR to the merge queue, our CI tests will not run. Graphite force pushes like normal, and usually this kicks off our github CI, but about 1/14 times it does not and only runs the Graphite mergeability check and a couple other third party checks, but not our github actions (which are using the

pull_request:

trigger). Because we have a required check, this causes the PR to get stuck. In order to fix it, one must make a trivial code change and modify/restack the PR. We can't tell what causes some PRs to behave this way, any ideas?

PR description generation seems to be very flaky today

I used to really love the graphite PR reviewer, but there's 2 very, very annoying things that are wearing my patience down and I might stop using it due to these, sadly: 1. Whenever you click a file name on the file tree on the left, it reloads that file, regardless of whether it was already loaded or not (why??) 2. I've reported this many times already. But the PR reviewer page constantly falls out of date with the current PR version since changes are being constantly pushed all the time. This prevents me from interacting (marking files as read, adding comments, etc) since you only allow it when viewing the most recent version. There should be a way to configure my account to always view the most recent PR. I never EVER bother looking at old version and honestly don't care for this feature, it only hurts UX without adding any value.