Hello, a few people in our team find that these stats are not useful and actually, by design, at any point in time they tell half the team they should be doing better. It would be great if there was a setting to hide them (at least for us, it would be even better if they didn't show up by default). Alternatively I would suggest to add a state that corresponds to "you are doing great!" for all team members that are within 1 or 2 standard deviations from the mean.

Here's a scenario where I had a stack of 3 PRs, and ended up merging the "bottom" (first) PR before the others. In this case I think the stack should update to show 2/2, and show these as 1/2 and 2/2, instead of staying as 3/3 and showing 2/3 and 3/3. Thoughts?

Could we get a setting in the CLI tool to disable showing the help text every time an unknown argument is passed? This tends to spam the console window, with how long that help screen is 🙂

Another nice-to-have: When working with a large stack, I merged the bottom 3 diffs, and still had a few on top. I then kept working at the top of that stack and wanted to create another diff. Submitting this PR triggered an update to all others (unmerged) PRs in the stack, retriggering CI even though code hadn't changed at all. Nbd, but just a bit annoying. Repro:

Submit PR stack
Merge bottom PR(s) with rebase method
gt sync (restacks and updates all local commits to new hashes)
*new code*
gt create; gt submit (updates ALL PRs in the stack, triggering CI for all of them)

I don't have a great solution to this, since it feels like a collision of git's "branch-based" vs graphite's "diff-based" methods colliding.

It would be nice to have some kind of

gt select

where I can pick which branch to go to interactively Since typing the branch names is a pain, and since other people or branches might not be using gt it would be good to distinguish my branches and branches with gt vs other branches EDIT: its gt checkout and its fucking cool

I’d like only 5-10 files shown here by default, with the rest hidden behind a “See More” button. I have to scroll a long time to get to the “Submit” button. I hardly ever want to choose only some of my files out of the hundreds I’ve changed, so there isn’t much value in showing them all by default.

escape

no longer takes me to the home page, and it's wonderful! Not sure if this is y'all responding to the feedback, or if it was an accidental regression, but regardless, I've noticed much less friction and annoyance because I'm not teleported away from my PRs anymore 😄

Hey team, would it be possible to add a setting to only show a PR in a single filter? For example, I have a section for PRs that are directly assigned to me and another section for PRs that are assigned to my team. If a PR satisfies both filters, it will appear in both sections, but I would like to have a way to only show it in the first one.

Using merge queue for a few weeks now, and it doesn’t quite work how I’d expect. It seems that CI only runs concurrently on PRs waiting to merge if all those PRs are in a single stack. In the extreme case, e.g. if 10 unrelated PRs are added to the merge queue at the same time, and CI takes 10 minutes each, then the queue will take ~100 minutes to clear. I’d expect it instead to rebase all of them into a “merge stack” and run CI concurrently + ff merge, as if they were all in the same stack. Is there a reason it doesn’t?

Wondering if it's possible to make graphite actually remove the branch from your branch list the moment you merge

Hey, our team is excited to try out graphite! Was wondering if there’s an email notification option for graphite?

Happy Thanksgiving to the Graphite team! I'm very thankful for this amazing tool that incredibly improve our workflow and the quality of the pull requests in the team. Today I'd like ask for a feature that would allow us to configure specific pull requests to send us a notification through either the browser or Slack once the PR has passed all the checks and is ready to be merged. Sometimes I require to do a manual merge (so the "merge when ready" feature isn't enough) and I'd love to be able to start the manual process as soon as the PR is ready.

by far the biggest complaint me and others on my team (who I'm slowly but surely converting to graphite!) have right now is that if you want to merge things higher up in the tree, you have to manually manage it, which is extra tricky if you're collaborating. basically, if I have

main < A < B < C

, am working with others, and want to merge B into A...it's not really clear what to do. when working alone, what I do is merge B into A via github, then fold B into A locally, squash, the force push. but this is not a very good process if you're working with others...I'm curious if this is on your radar? what do people do in this situation? for me, the big utility of graphite is how easy it makes making small, incremental changes that are easy to review etc. but if I make these changes and can't merge them like this, it has turned out to be a pretty painful process. if it's not in your roadmap, I hope you will consider prioritizing it, as thus far everything else has been really great

In the graphite UI in VS Code, it would be great to be able to submit the entire chain of PRs after everything was restacked Basically, I need the submit version of restack where everything in the chain, after I select restack, can be submitted

Long shot buuuut... I started using Raycast heavily Would love to see a Graphite extension (dev resources are great by the way)

Individual pricing? Doubt my company or team will start using gt, but I am, and I have no problem paying for the tools I use. Team pricing is too steep though when github pro is $4 a month.

Sometimes I run:

gt sync

gt trunk

gt ss -u

and I get

The stack you are submitting will have merge conflicts with remote.

It would be really nice to get some information about which PRs will have merge conflicts 🙂

Can we have a

gt update

command to update the CLI version within the terminal?

GitHub PR diffs show collapsed code block's first line, which makes it easier to understand where code is nested within a file. Graphite's diff does not. Is there a way to enable that?

✨ Separate feature request: We have Autolinks configured to automatically link references to Linear issues like ENG-123. It would be great if Graphite could import those settings, or provide its own support!

It would be great to have org-wide settings: • Default merge strategy: I'd like to enforce squash merge as default, but leave rebase available for specific cases so I don't wanna disable it in the GH settings • Default inbox filters: New users can benefit from some custom filters that aren't the default graphite offers, could be nice to set org-wide defaults, the "share filter"+notion page option is great for this already. • Slack notifications: unclear if my settings affect everyone's? I'd like that by default, everyone has some level of slack integration without them needing to go into their graphite settings

something like

gt pr --github

would be helpful for when i cannot manage the PR through graphite.

When I do a stack merge, I really like the fine grained controls like

Rebase after each merge

and

ignore optional CI checks

. But, I notice that when I have

Merge when ready

on, I don’t get the same controls. Is there a setting where I could change the MWR behaviour?

Merge bottom of stack, and change target of newest unmerged diff without

gt restack; gt submit

When merging part of a stack,

main<-A<-B<-C<-D

, let's say I merge

A

, I'd expect to end up with

main<-B<-C<-D

. NOT

stale-A<-B<-C<-D

. This is actually insidious, and possibly a bug, since if I then naively hit "merge" on B, I create a situation that I can't get out of using the UI, since now stale branch A has the commit from B. This is not the behavior on phabricator and is definitely not the user expected behavior. Github PRs auto-update their branch when merge stacked PRs, so this is also not the behavior on github. I've seen on the slack several times the recommendation that after merging a bottom commit, we should run

gt restack; gt submit

, but this just tells me that many people fall for it, and the cleanup is very annoying, involving several git operations I don't want to do day-to-day. I'd definitely consider this a bug if I didn't know it's intended by the Graphite team.

I'd love to be able to split my main review overview page into multiple pages. I have 5 categories for my own pull requests, and 5 categories for pull requests for which i'm a reviewer. To me they're different workflows I'd love be able to see separately at a glance. Bonus points if I could define a top-level filter for each (author = me, author = not me) to make creating filters faster.

Can

gt log

show whether a PR has checks busy running (or a summary of checks done / outstanding)?

copy URL to comment — i share link to comment on GH all the time in day-to-day workflow

Just a thought, could there be an option to turn this into an actual 2 x 6 grid? You'd have 2 options: a list or a grid to display on your dashboard. I think that would make it more sleek, but that's just me:

It would be a nice feature for free tier users to be able to see a list of open stacks, it’s frustrating to get a warning that there are 7 stacks open and have to manually go through all our PRs to figure out which stacks are still open

If you

gt modify --edit

the single commit of a PR, then

gt submit

it, it should update the title of the pull request (and possibly the body but I understand this can be more finicky)