Curious how the announcement of github to support stacked PRs changes things for Graphite. (disclaimer, I'm not a big fan of github but I can see folks from my organization move back to github native stuff and curious what is the mission to go forward to avoid this.... for instance getting rid of the difference on how stacks are shown in the PR overview pages on github, not close PRs when you use the graphite merge queue but show them as merged, etc.)

Good question! GitHub adding native stacking is something we've been tracking closely. Stacking is where Graphite started, but it's a fraction of what we do today — the code review UI, merge queue, AI reviews, notifications, inbox, automations, etc. — are where most of the day-to-day value lives. We see GitHub's investment here as validation of the stacked PR workflow more than anything. That said, the specific friction you mentioned is real — PRs appearing "closed" instead of "merged" from the merge queue is a known limitation we're tracking, and better integration with GitHub's native stack UI is something we're evaluating as their API matures. Both are on our radar! 😁

While I agree, many of my team unfortunately see it slightly different but use Github because of issues like lag of the Graphite UI when loading / opening a PR, no ability to search for PRs or look at PRs from a specific author unless you change the filters of your dashboard (and no, the shortcut to search for a PR of a person doesn't work at all), the merge queue being not being powerful enough to justify changing Github merges to also use it, automations, inbox and notifications are all available on Github as well, etc. -- Unfortunately, the features that you list that are clearly a benefit, are not strong enough to make people really engage because the workflow that you always do is slowing folks down (e.g. reviewing and loading PRs; getting an overview of open PRs (that you are not assigned as reviewer), etc. you need to go back to github anyways)... Long-story short. Yes, I agree that there are many features but what are the plans to keep the lazy engineer to leave their well-known environment if the first thing they need to do is overcome some things that are actually worse to finally get to the improvements.... (and I know its subjective. I personally use graphite for 99% of my stuff but its about a full engineering organization and not my preference...)