This message was deleted.

Does the copy link to GitHub in the ellipsis menu serve this purpose? Or are you looking for something else?

That takes quite a few clicks and a paste, vs a one-click action (which is ideal for me, at least)

This comes up fairly regularly 😕 (here are a few threads I see in my history). https://graphite-community.slack.com/archives/C04L3N3H34J/p1677697890207549 https://graphite-community.slack.com/archives/C02DRNZELUU/p1669232548089329

There are two issues from my point of view: 1. I’m not sure why I’d want to copy the url over just having that button take me to the github issue directly. 2. I don’t love that it’s in the overflow menu. I use that button more than a lot of other UI elements. That said, I’m guessing it’s ideal for you guys if we use this less and less over time. If I’m wearing my PM hat, I’d maybe solve (1) without dealing with (2). From my current user hat, I really would hope you do both.

Regarding #1 we heard from users that they just wanted to copy the link to send it to their teammates, and not to actually go to GitHub.

FWIW, I do both. I’ve written myself a little bookmarklet to do this that I use regularly, since about half the time I’m going to Github myself, and the overflow menu is too many clicks for such an important feature. Having Github access be low friction is the way Graphite enthusiasts like me can convince people to try it.

@Aryaman Is that because those users don’t want to force their teammates to use graphite? Somehow, I feel like if there’s an obvious “Goto Github” button, sharing the graphite url is just as good. I question why you need to share the Github url for a PR at all if the graphite review page is fully featured. I say this as someone who frequently prefers using the Github UI when reviewing code still. I don’t know if I could tell you why. It’s probably because on my 14" screen, the Github review UI provides ~420 extra pixels for the code itself when the side bars are open and I didn’t realize I could close the graphite side bar until just now…

Is that because those users don’t want to force their teammates to use graphite?

Yes exactly. cc: @merrill & @Xiulung Choy on this feedback

If someone is giving Graphite a try and they feel trapped and can’t easily get back to Github, they’re more likely to give up on it entirely. This has happened on my team at least once.

This happens to me all the time. I got fed up enough and created a TamperMonkey script to create a go back to GitHub button for myself.

Thanks @Bilal Quadri! Though I’d urge the Graphite team to reconsider this request. It’s the people we’re trying to woo from Github that matter. Graphite is so much better than Github at this point ❤️ -- y’all don’t have to introduce friction to convince users to stay.

Adding onto this - until the Graphite UI displays all of the information from the Github UI (or ideally a superset of it), I think it's necessary to have a "Go to Github" button. For example, I regularly need to check GitHub to see if I'm a code owner, which isn't shown in Graphite.

The lack of this feature is actually stopping me from using the graphite UI at all because its too hard to switch back and forth

FWIW, you should now be able to copy link to GitHub via the command bar, which should be easier than the multiple clicks it takes today.

If you want to make it even easier, just make it actually go to GitHub 😅

Thanks for hearing our feedback ❤️. It’s still two clicks,, plus a paste if we’re trying to go there, but I appreciate y’all reducing the friction here a little. @Aryaman Can I ask what the resistance to making this easy is? Is it a concern that people will not adopt Graphite if it’s easy to get to Github? Or something I’m not thinking of…

I'll let @merrill respond on this

Just wanted to add a +1 to wanting a link directly to GitHub. I feel like this would be a perfect place to put a "Jump to github link":

Hi all, First of all thanks for the feedback here - we hear you and want to make sure you feel comfortable and excited about sharing Graphite with your teams! To answer some of the above questions - here’s how we think about our north star with regards to interop w/ GitHub: • Graphite is built on GitHub’s platform - our goal is to enable a more efficient author & reviewer workflow for companies that use GitHub, while integrating nicely with all of the great GitHub features like Actions, Codespaces, and Issues that we don’t see as core to the Graphite workflow. • Graphite should display everything you need to review or merge without going to GitHub for >95% of PRs, and layer in additional functionality and context to help you do so more efficiently. • Graphite should help our users work seamlessly with teammates who aren’t yet on Graphite (i.e. with our stack comment, copying the GH link to share, redirecting logged out users to the GitHub PR page). • Graphite should help our users easily navigate from GitHub back to Graphite, so they can make use of Graphite’s additional features and context (i.e. with our stack comment + Chrome extension). The most helpful thing for us to understand here is what functionality do you find yourself missing in Graphite and navigating to GitHub to find? When teammates who are new to Graphite feel like they need to navigate back to GitHub, what are they looking for? We ask because understanding what’s missing on Graphite is the only way we can make the product better and work towards the above ideals. In many cases (i.e. showing

codeowners

info) we’ll prioritize adding the missing info to Graphite quickly (as we’re doing right now). For more complicated interfaces such as detailed CI logs and raw file views, we’ll link out to the relevant page in GitHub in a new tab. Again, appreciate the push on this - we know this probably isn’t the answer you want to hear, but hopefully the progress the team here has made on the dashboard over the past few months gives you some confidence that we’ll keep working hard until this doesn’t feel like a pain point. 🙏

For me, there's a few reasons that I bail on the Graphite UI and jump to GH. • On mobile, graphite is pretty un-usable. Github on the other hand works better and also has a mobile app. • 90% of my coworkers don't use and will not use Graphite, and get confused when I send them Graphite links. Redirecting when logged out by default sounds like a good fix here. • Code review pages have historically been slow to load (slower than GH) and unreliable. • I often reference things like Github Issues, other code in the repo, and other repos which is way easier to manage in Github's UI (and there's often no equivalent in Graphite) That said, for me, most of the value that I find is in the Graphite CLI + some value in the dashboard for knowing what I need to jump on. I'd even happily pay monthly to use it and turn off the Graphite review UI, although might be in the minority here.

@merrill Thank you so much for this wonderful response! ❤️ The things that come to mind for me are: • missing feature parity ◦ codeowners is an example, and I’m glad you’re working on getting to parity quickly! But we aren’t there yet, which is why people keep asking about lower-friction ways to get to Github. ◦ the mobile experience is a huge part of this too • bugs/regressions/reliability (this is a big one) ◦ Graphite isn’t yet at a state where regressions are rare. This means y’all are moving fast, often flying past Github with new functionality and better features (notifications, for example). It’s oddly a really good sign. But it also means that things like the merge button will randomly break or be erroneously disabled, or status is misreported, meaning we regularly have to search for the copy link, or open github and navigate to the PR manually. • familiarity / new user scaffolding (this is the other big one) ◦ For new users (there are many on my team), Graphite’s web UI is intimidating simply because it is not familiar. Having a low friction way to get to GH means they can get comfortable with Graphite over time. ◦ The metaphor that comes to mind is… if I put my cat into her carrier with some food and close the door, she’ll be less likely to enjoy her carrier. But if I leave the door open, she might even start hanging out there on her own. (This is a true story btw… now she sleeps in her carrier) I wrote a few weeks ago that Graphite is already better than Github in most ways. I think by making GH access high-friction, you’re more likely to scare off users. People keep using Graphite because you’ve built such a great platform, not because they forget about Github… so why not leave the door open for us? Thank you again for the conversation around this ❤️

Thanks for the info! To be completely direct, I have no desire to learn the Graphite UI. I'm not using Graphite because I'm missing any utility in the GitHub UI. I'm using Graphite for the stack mental model that the CLI provides and because your slack notifications are better 🙂. So essentially, there are value props to Graphite that don't include the review UI at all. As a user I should have the option not to use the review UI at all, IMO.

Thanks for all the additional context and feedback - it’s super helpful to hear where we’re falling short today. The good news is that we’re actively working on addressing many of these issues: • Mobile experience: @Aryaman is working on making Graphite more usable on mobile web this week as part of our Q1 hack week, and a mobile app is on our roadmap longer-term. • Missing GitHub entities (i.e.

codeowners

): @Brendan Ngo is actively working on ingesting & displaying

codeowners

on Graphite. We’ll also take a look at adding a typeahead for GH Issues with

#

, as well as searching for repos, files etc. • Correctness/reliability & performance: @Brendan Ngo, @Ziyao Wei, & @Nicholas Yan are working on a multi-month infra project that will address the known issues around Graphite misreporting PR/mergeability statuses. Their work should also yield significant improvements in PR page load times (in addition to major improvements we’ve made here in the past couple months). • Familiarity & new user experience: We’re planning changes to help new users better configure and understand how to use the Graphite PR page more intuitively. A couple more changes in-flight to help with GH interop: • @Jacob Gold is updating our Chrome extension to be less aggressive - it will soon just add a button to the PR page in GH to let you navigate back to Graphite vs. the (buggy) auto-redirect behavior. • We’ll prioritize fixing the redirect on Graphite links to GH for logged out users. @Ben Jaffe I like the crate training metaphor - could be an interesting hypothesis for us to test with a cohort of new users! @Jordan Gensler when you say “90% of my coworkers will not use Graphite” - is there a particular reason why they wouldn’t ever give it a try? @Matthew Keller heard re: not getting value out of the review experience today - it’s on us to keep pushing and iterating on the review experience until it feels compelling, and that’s what we’re going to do. At a high level we’re not here to build a piecemeal assortment of features and plugins - our goal is to build a highly integrated workflow tool that helps our users create, review, and merge code changes more efficiently. That doesn’t meant that we expect everyone to use every part of the experience we build, but our priority is to help more users and teams adopt Graphite end-to-end and provide the best possible experience for those who do.

@merrill I've convinced the folks on my team to give it a spin but there's not interest in the other engineering teams. My team has had issues with long-running branches and review backlogs, whereas other teams don't run into those issues nearly as often for a variety of reasons.

I’ve had my own reasons for wanting to be able to go back and forth easily between Graphite and Github. Today, I do most things in Graphite’s UI, but for some tasks, I pop over to Github before popping back. The default friction bothered me to the point that I needed to use a browser extension to modify the UI to my needs. 1. Graphite doesn’t cover all features that Github’s UI has. As Github releases new features, there will always be some delay before Graphite adopts them. Some features may not get adopted at all. For this reason alone, an escape hatch is warranted, IMO. 2. Getting into the specifics of features I’ve recently noticed missing in Graphite: a. Rendering of mermaid diagrams b. Rendering of rich Jupyter Nodebook diffs (not using this much yet personally, but it’s something we’re interested in) c. Syntax highlighting of code suggestions d. Ability to commit/batch code suggestions e. Ability to view list of which files a merge conflict impacts f. Context of collapsed lines in a diff. Graphite just shows up/down carets while Github will say things like

@@ -211,7 +211,7 @@ export class DocumentEmailStateMachine extends Construct {

g. Other things too that I can’t remember off the top of my head 3. There are cases where reliability issues require me to jump to Github for a source of truth. PRs not appearing as part of a stack when they should, merge job failures, etc. This is pretty rare, but I like having the escape hatch for peace of mind. Lately, Github itself has had many issues, and it’s helpful to be able to pop over and confirm that it is indeed Github at the root cause of the issue. 4. It’s a personal preference, but I like the syntax highlighting and background color of the theme on Github Dark more than Graphite. Sometimes, when a PR is hard for me to make sense of, I like to open it in Github to get more comfortable readability. The actual diff highlighting is better on Graphite though. Then again, the lack of contexts on diffs still has overall easier reading on Github. 5. Would love a way to be able to flip the sidebar to be on the left side instead. Github has it that way, and it’s just more comfortable for me since literally every other place I read code also does it that way (Github, VSCode, Neovim CHADTree, etc). 6. Sometimes I want to go to Github to search/read other code in the repo that may be affected by the change but aren’t in the diff. Can’t do that in Graphite so I need to be able to popover to Github quickly for that flow. 7. It was already mentioned and you already have plans for it, but mobile is pretty broken. Clicking on a graphite slack notification from my phone is frustrating. In the short term, I can probably solve the pain by just logging out of Graphite on mobile so it has the go to Github button again.

Coming into this thread a little late, just wanted to +1 some other people’s thoughts: • Often I end up wanting to use GitHub instead because about 80% a nontrivial amount of the time I review with Graphite I get this red box that says “An unknown error occurred: Some data may have not been saved.” ◦ So then I just abort and go to GitHub • The review UI is snappier in GH (since its native, of course). So there’s no lag between typing a comment/starting a thread and it showing up in my review ◦ Or if I’m trying to close the Graphite tab I often get the “Your changes might not be saved” alert • In GH I can add a comment to a whole file (I think this is new functionality, which is pretty cool) • In GH I can reply to threads immediately, vs in Graphite you have to “add a reply” and then “submit comments”. • While I’ve been using the Graphite review UI for awhile now, the code review colors/layout in Github still feel more comfortable (for a bunch of reasons I listed in a thread awhile back about busy-ness and colors of the Graphite UI) Looks like you guys already have things in works to address most of these though; so I shall wait patiently 🙂 Thanks for all the hard work, as usual

Just to underline the reliability point, yesterday I started not using Graphite web at all because of the intermittent loading issues. I would have preferred to keep using Graphite web, and only pop over to github whenever things were slow. The friction around getting to github meant I just gave up on Graphite. This same psychology is what I’m afraid will happen for new users as they’re learning Graphite, suddenly get overwhelmed with work, and say screw it, I’m busy, I’ll fall back to what I know and use Github directly. I’ve already seen this happen on my team with at least one person, and if y’all made it as easy to get to Github as your chrome extension makes it to get to Graphite, I doubt they would have given up.

Ran into another use-case for going back to Github. PRs with multiple collaborators have different commits authored by different people. No way to see who authored what without going to Github.

This has been a rough few weeks for Graphite around bugs and outages, and so we've all probably been feeling the pain of how many clicks it takes to get to Github. Without choosing to, I found my fingers going starting to go straight to Github instead of trying Graphite first. Eventually I made a chrome extension for myself to implement the buttons, but most users probably won't do that. In previous threads around links to Github, we've been asked about why this request so important, and many of us raised stability concerns. I know the decision isn't likely to change any time soon, but in case y'all ever do revisit it, I wanted to put a pin in this moment as an example of how instability can lead users away from Graphite, and how interoperability with Github might keep them coming to Graphite first. I'm writing in this dusty thread because I don't want to reopen this discussion publicly. Separate from that product decision though, I'm sending all the positive vibes your way... outages and regressions are no fun. You're all doing amazing work, and I really appreciate all of you. ❤️

Thanks for flagging - you’re absolutely right that the past few weeks have been rough, and we’re sorry for letting you guys down. We know we need to do a lot better on product stability if we want to be a product you & your team trust to do your work on every day. The somewhat ironic piece here is that many of the recent outages and bugs have resulted from tracks of work intended to improve long-term stability and performance. For example, the commenting bug yesterday happened as part of changes that should make adding a new thread feel instantaneous (rather than the 1-3s delay). It’s not an excuse, but hopefully it’s some comfort to know that the short-term pain is indicative of our efforts to address some of the largest & longest-standing pains around Graphite before launch. We’re also focusing a lot more on stability as a team by introducing internal SLOs and starting an SRE guild, which @Brendan Ngo on our team has been championing. Really appreciate the positivity as we navigate all of this - Graphite is a large, complex, and challenging product for a team of our size to build and maintain, and we’re working hard to make it a great experience for y’all! 🙏

I appreciate the reply @merrill, thank you, ... and understand that you probably can't comment directly on the key point I'm making. I have a ton of trust in the eng team around these improvements, both short and long-term (I can't wait for the commenting changes!). But despite the dream we're aiming towards, regardless of the great features that are just weeks away, we're still a long distance from reaching the uptime/parity dream. I'm sure I'm sound like a broken record, and I apologize for that, but using my chrome extension that adds links to Github (for both copying and opening) has taken all the emotional teeth out of Graphite having downtime because the fallback (Github) is easy for me to access. Until Graphite becomes a super stable product with three 9's of uptime (or at least two) and full feature parity, most of your users will keep regularly having these moments where they need to fall back to Github by clicking through a menu, and copying and pasting a link. I think the friction here will significantly compromise Graphite's adoption with new users (and keep annoying existing ones). In other words, they'll revert to using Github and some just won't come back (especially in context of the new payment plans). I hope you know that the only reason I'm still here saying this is because I really believe in all of you and see you consistently do incredible work... It's very painful to see a company that I love insist on not removing the gun they're aiming at their own foot. 😩