Tips for resolving common Graphite CLI issues.
gt feedback
and sending debug logs. This allows us to fix most issues.
gt dev cache --clear
is a safe command that sometimes fixes inadvertent issues that we haven’t caught before release. It doesn’t change any git
or Graphite state.
gt untrack
specific branches that are behaving weirdly. You will then need to re-track branches with gt track
– note that in certain cases you may need to git rebase
manually in order to track a branch with the correct parent. Read more about gt track
.
gt init --reset
is the nuclear option which deletes all Graphite metadata from your repository. All branches will need to be re-tracked.
gt feedback
sends us are stored at ~/.local/share/graphite/debug
(or $XDG_DATA_HOME/graphite/debug
). Each file contains the logs for a single CLI invocation, and includes information about underlying git commands and network requests. Logs are stored for 24 hours —gt feedback
sends the whole directory. If you encounter any issues with the gt feedback
command, feel free to zip the directory and include it in a support ticket to support@graphite.dev. You can also go spelunking in the logs yourself if you are curious!
git push --force-with-lease
under the hood for our push, which should ensure this doesn’t happen. You should only be able to overwrite changes that you have already pushed from your machine or synced to your machine with gt get
.
Using this option is just like using --force
(push to a branch on remote even if remote’s SHA cannot be fast-forwarded to the new SHA), with the caveat that if the remote’s SHA for the branch doesn’t match the “remote-tracking branch” on your machine (for example, refs/remotes/origin/feature
), it will fail, as this means that someone else has updated the branch since you last pushed to it or pulled it. Graphite respects the “remote-tracking branch”, only updating it on a gt submit
or gt get
operation.
The issue can arise if you have some other tooling (for example, some VS Code extension) that is git fetch
ing your branches in the background. This could update the “remote-tracking branch” and result in the --force-with-lease
check passing—even if someone has updated the branch to a commit that you haven’t synced to your repository (or pushed yourself).
gt stack submit
both performs a git push
and a GitHub API call, occasionally GitHub will pick up both as a synchronize
event on the PR.
We recommend using GitHub’s concurrency configuration to ensure that you do not have duplicated CI.
For example, the following configuration will cancel previous CI runs on the same pull request:
gt submit
after a GitHub repository has been renamed, you may encounter a 500 error from the pre-submit-pull-requests endpoint, even though repository syncing works correctly within Graphite.
Even though GitHub redirects old repository URLs to new ones for Git operations, this redirection may cause issues with gt
’s PR submission process. Ensure both your Git and Graphite configurations are updated to use the new repository name directly:
gt config
to access Repository-level settings
> Remote repository
> Configure repo name
and update the repository name to match the new repository namegit remote set-url origin https://github.com/owner/new-repo-name.git
to update your Git remote origin to point to the new repository namegt modify --commit
, and if you end up with multiple commits on a branch by accident, you can always use gt squash
to get your branch back to a single commit. This way, you can essentially only use gt
, and your workflow will look something like (making use of lots of shortcuts and short-form flags):
Terminal