Would it be possible to get per-workspace user settings? I started working with a second org that uses graphite and there are thinks that are locked to the user instead of user+workspace. This leads to email, username, signing, etc leaking between companies which isn't ideal. For example: • Notification email • Merge Queue email • GPG signing key email • Slack integration

Composable dashboard sections would be awesome. We almost have this right now: you can use your own share link, then add another filter. So I guess i'm just asking for a "DRYer" version of this so i don't have to "manually rebase" my filters? (very meta graphite fractal)

the Graphite UI has this amazing ✨ Generate button for AI-assisted PR descriptions. Would be great if that was on option in

gt submit

. It could just flag it to run once uploaded to graphite but at least by the time the devs open the PR the description is there ready to be reviewed already.

Shift

+ Down arrow should prioritize unresolved threads first

Want:

gt absorb

flag that aborts if there are any changes that would not be absorbed.

merge when ready should allow us to mark as hotfix

would be nice for vscode to have common workflow items in the command palette

For graphite reviewer, can the GH action please show that it's re-running when a new commit gets pushed? this is one fo the only "downsides" we've found coming over from other AI reviewers

Another request for code review: org-wide setting the default value of "review draft PRs". we'd love to default that to true

would be nice to be able to star a co-worker's stack so i can keep track of it

would be nice to have the currently open merge editor highlighted in the graphite vscode ui

vscode plugin: would be nice if we could drag diffs ONTO diffs (the current behavior) AND drag them BETWEEN diffs currently reordering is a two step operation that can be kinda confusing if the tree is complex. here's how you currently move a diff down the stack with two operations that could be one

it would be great if sync would automatically grab the upstack from remote instead of having to

gt get

the top of the stack (created by another user)

vscode extension: show frozen status indicator on frozen diffs. unfreeze (with confirmation) when clicked

gt unfreeze

with no arguments could unfreeze all diffs on the stack

maybe silly request but i'd love to be able to edit PR commit messages from the Graphite web PR view

Thoughts on preventing the merge queue from making 2 PRs if there is only one PR in the stack? My team is using the merge queue but even hotfixes take 3 build cycles to get promoted to main when it should normally only take 2 - branch + main

i'm tracking a co-worker's branch and the name is the first commit message which doesn't accurately describe the PR. the PR name is more accurate. would be nice to have it use the PR name by default or at least allow us to rename the branch we are tracking locally. (this co-worker is not using graphite)

It would be quite nice to have an integration with jujutsu vcs, their way of dealing with conflicts as first-class objects is great and they already offer a very nice workflow around stacked PRs, however graphite doesn't seem to play well with it. (Or I haven't found a nice way yet)

[Multiline input field in VSCode Extension] In the VSCode extension, it seems that I can only write a one line message in the input field. It'd be great to be able to write the commit title + commit description on multiple lines. Right now I have to leave VSCode and run the

gt create

command manually when I want to write more context in the commit message. Bonus: Having the AI button and + warning squiggles similar to the input field of the VSCode default Source Control panel would be awesome

[gt modify mid-stack branches] When working at the top of a stack, I often stage some changes and already know which commit in the current stack I’d like to amend. 2 cases: 1. The commit to absorb the change is clear -> I use

gt absorb

🚀 2. Otherwise, I currently do:

stash

,

checkout

,

modify

,

top

,

stash pop

It'd be great if I could deal with case #2 faster, maybe with something like

gt modify --branch <BRANCH>

or

gt modify --interactively-choose-branch

?

I'd like to pay for graphite personally and be able to use it in any organization (even if my organization doesn't use graphite), it can use my PAT do the stacking, all I care about is stacking, nothing else.

Want: rich/formatted markdown viewer in graphite web PRs.

A bit of feedback on this new UI that just showed up (which looks nice otherwise). On a CI check my primary action I'm going to want to take is to go to see the details of why a CI check failed. It's now hidden behind this very subtle button. I honestly just want to to click the name to go to see CI. 😅

We use the Merge queue and it makes me sad that to actually urgently merge CRs/hotfixes our team goes to GitHub and merges through them instead of the merge queue hotfix being helpful (it has to run CI SO many times)

small idea: could we make it possible to right click open in new tab in the inbox? if each row is a custom button that doesn't support that maybe instead there could be an open in new tab icon button?

would be cool if this would restack automatically. this particular one did not have any merge conflicts

I'd like to have more config options in

gt config

to control things like: •

gt get

- I always want the

-U

variant •

gt co

- I always want to fetch from remote if it isn't available locally •

gt submit

◦ I always want to delete branches that have been merged ◦ I also always want the

-n

flag set since I provide everything on the cli I have workarounds for these with aliases (except the

gt submit

prompting about deleted branches - I just do

gt sync -f

first).

I think being able to exclude lock files from the diff on when generating the description with ai could be cool. I'm having that issue when using uv.

Feature request: the ability to mark a subset of a stack as "squashable". Approval on all of the component PRs should result in all of them being merged together into a new branch and PR prior to the stack entering the merge queue. In the ideal world, Graphite would transfer approvals from component PRs to the new PR (i.e., it would gain permission to act on behalf of engineers to apply their approval to the resulting PR). That may not be possible, though, so maybe Graphite would just auto-approve this new PR using a system user, since all component PRs were approved. (This won't work for companies that require more than one approval, or specific approvals from code owners, so obviously some work to do there 🤷)