Graphite Community

image.png

We're thinking about improvements to the filters! cc <@U02DCQ1C0G6> and <@U04HQKF7TSN>

hmm weird `cmd+j` should definitely allow you to just leave comments

cc <@U02DGFZ1H0D> / <@U02DCQ1C0G6> on the discussion we had a while back

this is a limitation of github which requires a review to add comments. the `cmd` + `j` should submit thread comments if you press it while on the pr page and have pending comments. it doesn't work while the review modal is open and or if you're in a text box somewhere. Where have you tried using it?

Right, so there's no way to add thread comments as single comments via the API like in the GitHub UI?

I was under the understanding that cmd + j would allow me to leave a single reply without having to submit a review!

If this is a limitation of the API then that's totally all good :smiley:

<@U03FNT1FLP5>, confused what you mean by cmd j not working for you. I just tested and it works. So my flow is:
1. `Add reply` on existing thread or start a new thread via clicking on the line numbers
2.  Type comment
3. cmd enter to save the thread
4. cmd j to save the review


<@U04HQKF7TSN> oh! Then I was being stupid. I was attempting to use cmd + j instead of cmd + enter!

God that really makes me look dumb haha. With that, I don't need to enter a review then?

After you hit cmd enter, your thread comment will be saved as draft, and then you will have to do cmd j to actually publish it. Ideally we should make this a single shortcut rather than requiring two steps (cmd j, cmd enter).

Riiight! That's where my understanding broke down. I thought it was a single shortcut. Will give this a go asap, thanks again!

cmdj.mov

Take a look at this video for the full flow if you still have questions. I hit cmd enter at 18 seconds, and cmd j at 24 seconds.

Exactly what I'm looking for, thank you!! (A button for idiots like me for this would be great)

Agree, we're thinking about this :slightly_smiling_face:

that's on us for not making this clear! as everyone else said, we're thinking about the ergonomics here

Preview markdown (and similar files) option.
In Github, you can select `view file` from the `…` menu of a md file to see it rendered as markdown, which is useful to spot markdown mistakes.
It would be nice to have a similar feature in Graphite.

Aw I'm sorry this happened, and great suggestion! cc <@U03Q89DJPL4> for description editing viz

`gt stack submit` does have a `--reviewers` flag you can use to assign reviewers when you run the command. Would that meet your needs?
```  -r, --reviewers    If set without an argument, prompt to manually set
                     reviewers. Alternatively, accepts a comma separated string
                     of reviewers                                       [string]```

ah! of course! I was checking out `gt stack --help` and didn't see it there. i think it should be exactly what I need – let me check it out and get back to you

Will throw this into the docs as well :slightly_smiling_face:

Would be nice for the interactive reviewer selection to work also for already submitted PRs:

```(backend-py3.11) ➜  backend git:(02-27-refactor_tests) gt downstack submit -r      
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ 02-27-fix_field_descriptions (No-op)
▸ 02-27-add_net_co2e_removed (No-op)
▸ 02-27-refactor_tests (No-op)

🆗 All PRs up to date.
(backend-py3.11) ➜  backend git:(02-27-refactor_tests) gt downstack submit --reviewers
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ 02-27-fix_field_descriptions (No-op)
▸ 02-27-add_net_co2e_removed (No-op)
▸ 02-27-refactor_tests (No-op)

🆗 All PRs up to date.```

Hey there, just tried doing this to an existing stack and it didn’t work. I entered the github user name string (no @ or anything in front), and when I went to the stack after having submitted, none of the PRs had a reviewer set. Didn’t get an error or anything either

You can do so in the dashboard! We generally recommend editing PR descriptions in the dash since theres waaay more functionality

To be honest, I’d really prefer not to have to jump to a browser while I’m working. It’s so distraction-prone.

I’m able to edit commit messages right alongside the code that I’ve edited and the output of shell processes, so I have the most context there. Editing in the browser means either setting up split windows or constant Cmd+Tabbing between my terminal and Chrome.

One other issue I have with the web UI is that it doesn’t help with keeping max column widths for lines. I try to wrap lines at 72 characters, and that’s impossible in the web dashboard. I find myself copy/pasting the PR description into Vim, formatting it there, and then copy/pasting it back into the dashboard.

Bumping this feature request. I keep running into this limitation and manually updating my P/R description. <https://graphite-community.slack.com/archives/C02ENKC0A9X/p1677694651697709>

You can edit PR descriptions from the command line with `gt ss -e`

cc <@U03Q89DJPL4> for merge-related requests

CC <@U02DCQ1C0G6> <@U02DGFZ1H0D> I believe they will have more context on the history/future here.

Hey <@U04KWBNA1HV> sorry for the delayed response.

So today, Graphite uses whatever default branch you have set in GitHub to determine where stacks “should” be merging into, and since the repo’s default branch is set to `main` Graphite wanted to warn you that were able to merge into a branch that isn’t the default branch.

Perhaps the messaging is too forward and we should probably change this to a warning that reads `This stack is merging into Feature_Branch and not the repo` 
In the long run we want to update the web app and the CLI to be more aligned in regards to the base of the stack and make it easier to set and change.

Do you regularly switch between trying to merge into a feature branch and into main?
Do you need to merge into the feature branch first before handing off to QA?
Do you have a perspective on what the ideal workflow would be for you here?

Something you could do: respect the git config `rebase.autoStash` on `gt rs -r`
Currently I'm doing `git stash push &amp;&amp; gt rs -r &amp;&amp; git stash pop` when I want to rebase with the remote and have some work in progress
(I understand that would mean handling conflicts on `pop` which might not be as easy as it sounds as git keeps the stash when the apply fails)

Super interesting. cc <@U02DCQ1C0G6> for a design approach to this request

We don't have a VSCode extension yet— this isn't us!

Have you checked out the "Reminder Digests" here? <https://app.graphite.dev/settings/notifications>

We do something like this!

yeah, I do get those to remind me to do reviews. I was referring to a section more like the web dashboard since the live updates drowns out the reminder digests and they get outdated

using the slack app homepage as a mini-inbox is a neat idea! thanks for suggesting :slightly_smiling_face:

Screen Shot 2023-02-28 at 6.21.22 PM.png

Not sure if this is a bug or a feature, but when I make `gt stack submit` calls and graphite puts together updates to existing PRs, sometimes it pulls in more branches than are relevant.

For example if I have a stack off `dev` and someone else also has a stack off `dev` on my team, their entire stack gets referenced in my auto-generated commit messages, even though I’m not tracking their branches with my local `gt` CLI

Is that a configurable behavior?

Here’s a screenshot that might help

Can you add `monospace` to the code style preferences? That way the browser will use my globally configured monospace font.

Not gone away yet. At some point when we have time we'll have a setting to toggle it on/off, but if it's not happening for you seems more like a bug.

cc <@U03Q89DJPL4> <@U02RREE9GKH> who are working on updating merge

Hi Anish! We are hoping to have it ready for use by the end of the month, but I can't say for certain yet

Starting a beta group for this! Make sure to react/reply in thread if interested :slightly_smiling_face:
<https://graphite-community.slack.com/archives/C02DRNL3HQU/p1683923375949469>

For now you can use `<http://app.graphite.dev|app.graphite.dev>` but this should be fixed soon <@U04K5N14V9B>

copy! looking forward to the fix!

I have to type all the way to `app.g` for the autocomplete to succeed :cry:

`gt branch/stack submit --no-edit --publish/draft` should get you what you want

yep! `gt ss -np` is probably my most run command :slightly_smiling_face:

I haven't tried it, but there is also `gt branch submit --no-interactive`

I guess I should’ve looked at `man` first. Thanks though :slightly_smiling_face:

<https://graphite.dev/docs/graphite-cheatsheet#gt-ss--np> :saluting_face:

This is probably my biggest gripe with Github, that it encourages people to push tons of tiny commits that just adds notifications, even when it’s not ready for review

Love this suggestion! cc <@U02DGFZ1H0D>/<@U04AP0M9AES>

And the reason why I usually keep a flat commit stack with one commit per branch. But even if the only way to make this happen was to have a comment associated with a commit, I would change my workflow to have this feature and treat each commit as essentially a revision in Phabricator terms

But either way would love just a way to leave a commit with an update to a PR

This would be super useful too on the compare revisions dropdown because all there is now is a list of commit hashes and sometimes it’s hard to tell which ones I should be comparing against

<@U02E6THB4Q5> good idea - we’ve been thinking about creating a way to “name” versions (from the web and the CLI) and then show the version names in this dropdown instead

Does a hard refresh of the site (command-shift-r) resolve the issue?

Haven’t tried a hard refresh because doing the actions have worked after a refresh or sometimes just leaving the page and coming back

I do see this in my console tho. There are a lot of them similar to this

Getting the same thing today. Reviewing a large PR approx 5k line changes. Happening a lot marking files as viewed seems to cause it a lot. Haven’t noticed any comments not being added yet

`--parallel` we'd need to use worktrees for i imagine, but i like that too

Just replace `&amp;&amp;` with `;`

This is a common pattern for me

```gt add .; gt continue```


One of my most commonly used ones is `gt rs; gt sr`

<@U03FNT1FLP5> fyi `gt rs -r` will also restack after syncing!

FYI, `;` will continue with the next command, even if the first one failed (which could cause issues in a long string of commands). `&amp;&amp;` will stop if any of the commands fail.

`gt add .; gt continue`
-&gt;
`gt cont -a` :smile:

There’s a bloody command for everything :muscle:

Coming soon as part of a paid Graphite for teams product

cc <@U02E95J4648> -- didn't you build this?

Screen Shot 2023-03-08 at 1.33.30 PM.png

Screen Shot 2023-03-08 at 1.32.59 PM.png

I believe the historical reason is that we have `gt branch checkout` so we don't pass that one through — but it should be perfectly safe to use `git checkout -` in between graphite commands!

Do you have any concerns about me adding it to the allow list? <https://github.com/withgraphite/graphite-cli/blob/8e6b5e3d1b1da2bb49d3a27feccfc103ee46a628/apps/cli/src/lib/pre-yargs/passthrough.ts#L5|https://github.com/withgraphite/graphite-cli/blob/8e6b5e3d1b1da2bb49d3a27feccfc103ee46a628/apps/cli/src/lib/pre-yargs/passthrough.ts#L5> main motivation is to be able to keep using `gt` seamlessly instead of `git` but I’m fine either way :) 

We have only included commands in the allowlist that don't have a graphite equivalent — of course there is a trade off because we don't have functionality equivalent to `checkout -` but we'd like to keep it this way to reduce ambiguity w.r.t which command to use.

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 :confused: (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.

<@U04HQKF7TSN> 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…

So maybe my behavior changes now that I know that, but it wasn’t too obvious to me.

&gt; Is that because those users don’t want to force their teammates to use graphite?
Yes exactly.

cc: <@U02DGFZ1H0D> &amp; <@U02DCQ1C0G6> 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.

Here’s the quick and dirty TamperMonkey script I created in case anyone else gets value out of it:

```// ==UserScript==
// @name         Graphite Github Button
// @namespace    <https://zoya.finance>
// @version      1.0
// @description  Create a nav link to open Github PR from Graphite
// @author       Bilal Quadri
// @match        <https://app.graphite.dev/*>
// @icon         <https://www.google.com/s2/favicons?sz=64&amp;domain=graphite.dev>
// @grant        none
// ==/UserScript==

(function() {
  'use strict';

  const navBarSelector = '.pull-request-title-bar'
  const githubButtonId = 'tampermonkey-github-button'

  const displayLink = () =&gt; {
    if (document.getElementById(githubButtonId)) {
      return
    }
    const navBar = document.querySelector(navBarSelector)
    if (!navBar) {
      return
    }
    const [, owner, repo, prNumber] = window.location.href.match(/\/github\/pr\/(.+)\/(.+)\/([0-9]+).*/)
    const githubLink = `<https://github.com/${owner}/${repo}/pull/${prNumber}>`

    const githubButton = document.createElement('div')
    githubButton.innerHTML = `
      &lt;a class="buttons__button" id="${githubButtonId}" href="${githubLink}"&gt;
        &lt;svg xmlns="<http://www.w3.org/2000/svg>" fill="#ffffff" width="24" height="24" viewBox="0 0 24 24"&gt;
          &lt;path d="M12 0c-6.626 0-12 5.373-12 12 0 5.302 3.438 9.8 8.207 11.387.599.111.793-.261.793-.577v-2.234c-3.338.726-4.033-1.416-4.033-1.416-.546-1.387-1.333-1.756-1.333-1.756-1.089-.745.083-.729.083-.729 1.205.084 1.839 1.237 1.839 1.237 1.07 1.834 2.807 1.304 3.492.997.107-.775.418-1.305.762-1.604-2.665-.305-5.467-1.334-5.467-5.931 0-1.311.469-2.381 1.236-3.221-.124-.303-.535-1.524.117-3.176 0 0 1.008-.322 3.301 1.23.957-.266 1.983-.399 3.003-.404 1.02.005 2.047.138 3.006.404 2.291-1.552 3.297-1.23 3.297-1.23.653 1.653.242 2.874.118 3.176.77.84 1.235 1.911 1.235 3.221 0 4.609-2.807 5.624-5.479 5.921.43.372.823 1.102.823 2.222v3.293c0 .319.192.694.801.576 4.765-1.589 8.199-6.086 8.199-11.386 0-6.627-5.373-12-12-12z"/&gt;
        &lt;/svg&gt;
      &lt;/a&gt;
    `
    navBar.insertBefore(githubButton, navBar.lastChild)
  }

  // Run on interval in case React re-rendering removes it for some reason.
  // Doesn't seem to be an issue right now, but no need to risk it.
  setInterval(displayLink, 1000)
})();```

Thanks <@U02NXEUP3G8>! 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 :heart: -- 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 :sweat_smile:

Thanks for hearing our feedback :heart:. 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.

<@U04HQKF7TSN> 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…

Screenshot 2023-03-29 at 6.09.15 PM.png

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 &amp; 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 &gt;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. :pray:

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.

<@U02DGFZ1H0D> Thank you so much for this wonderful response! :heart:

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 :heart:

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 :slightly_smiling_face:. 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*: <@U04HQKF7TSN> 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`)*: <@U0486U7UUF3> is actively working on ingesting &amp; 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 &amp; performance*: <@U0486U7UUF3>, <@U047KHH8JH3>, &amp; <@U02DGG36CSH> 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 &amp; 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:
• <@U02RREE9GKH> 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.
<@U045W8WMUN5> I like the crate training metaphor - could be an interesting hypothesis for us to test with a cohort of new users!

<@U04RXRV9K35> 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?

<@U04TDDYNDMH> 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.

<@U02DGFZ1H0D> 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 :slightly_smiling_face: 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. :heart:

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 &amp; 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 &amp; 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 <@U0486U7UUF3> 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! :pray:

I appreciate the reply <@U02DGFZ1H0D>, 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. :weary:

Screen Shot 2023-03-10 at 9.56.12 AM.png

I'd love an option to make text smaller than 12px (or set the size manually). We have an 80-character line limit in our repo, which means that comments are often in the 70-80 character range - this results in hard-to-read code in the PR view, as it wraps just one or two words each time. So, I'd love to make the text a little smaller so that just about 80 characters can fit on one line at a time.

`gt branch fold --down`  = `gt branch fold`

`gt branch fold --up` = `gt bu &amp;&amp; gt branch fold --keep`

haha we've been having a lot of debates about relative vs absolute timestamp internally - we should have an update here soon!

Toggle on click would be nice. Could default to relative time and switch when clicked.

(This is also something I loved from Phabricator - a multi-column, relatively dense, but very functional dashboard where I could see everything that was relevant to me on a single screen, without having to scroll around)

Ahh this is super interesting! Split screen between inbox sections could be cool :eyes: (cc <@U02DCQ1C0G6>)
As for scrolling up and down a bunch, a quick way to fix that is to click on the section title in the left side to jump to that section directly rather than having to scroll

While this doesn't solve your exact problem, there are some upcoming improvements to dashboard sections filtering that should improve your experience here, and hopefully make things more clearly actionable.

<@U04K5N14V9B> I guess the problem isn't exactly the scrolling, and more the fact that I can't see everything I care about at the same time, while there's also a bunch of empty space. But thanks nonetheless!

Gotcha - good to know, taking note of this suggestion :))

I’ll second wide-screen optimization, and the more broad point too around information density… I regularly forget which panels on the right have what info, and even with keyboard shortcuts and after several months, it regularly takes me a few clicks to find what I’m looking for.

There are also planned improvements to the right side panel that <@U04AP0M9AES> is working on.