Graphite Community

And not just for SVGs.
Also for Markdown files, AsciiDoc files, and probably others.
Native GitHub has this abiilty.

Great idea, we'll look into this when updating the filtering experience

Yeah we have wanted to fix this experience for a while, just not had the bandwidth to do so.

Thanks for the suggestion! Taking note of it

"Blameless mode": replace every mention of `blame` with `praise`  in the UI :stuck_out_tongue_winking_eye:

Not sure whether this is a bug or feature request.
I submitted my shiny 20 PR stack without specifying `-r`.
Now I wanted somehow to bulk-request review, but I did not find a way (besides using GitHub directly).
Even `gt ss -r mymate --always` did add a new version without changes to the dashboard PR view, but did not request the reviews.

Screenshot 2023-06-02 at 1.45.21 PM.png

<https://graphite-community.slack.com/archives/C02DRNZELUU/p1685705370065619> :wink:

:facepalm: should’ve just looked up a little haha

<https://marketplace.visualstudio.com/items?itemName=trunkflow.trunk-flow&amp;ssr=false#overview>

Would it be similar to this <https://sapling-scm.com/docs/addons/vscode/|https://sapling-scm.com/docs/addons/vscode/>?

image.png

Thanks for the feedback <@U05447TKZKP>. I’m curious to know what your preferred settings for FiraCode is. We could perhaps just set it as the default way to display FiraCode in our product.

This is my preferred current FiraCode setup:
```docker run --rm -v "${PWD}":/opt tonsky/firacode:latest ./script/build.sh -f "ss02,ss03,ss04,ss05,ss06,ss07"```
The font file generated by this I install in the system, as many softwares / places do not support selecting font features, so with them baked-in at build time it works nevertheless, as long as I can select the font I want to have.

And advantage of `monospace` is that we can use it to display proprietary fonts (by setting up our os/browser).

That's probably the main reason they might be hesitant to do it, because they then don't control how it looks and risk breaking the display by user setting :confused:

You can! It's in the `...` menu when you're typing up a comment

We've had some requests to make this a bit more discoverable though

I don't see the dots-menu.
Neither on editing the description, nor on adding review comment.

Ah, it's there on the line-comment box, but not on the overall review comment box.
Then take this as additional voice to make it more discoverable,
but more importantly to have the functionality everywhere you can write markdown.

Ah ok got it - you wanted to see it on the overall review comment. Thanks for flagging, we'll look into it!

Either there, and / or when editing the description, don't remember.
I actually want it everwhere marrkdown is (or will be like the title) supported. :slightly_smiling_face:

Got it - description has the live edit preview so that shouldn't be an issue but I'll raise the other areas!

Ah, yeah, right, once it supports linebreaks properly. :smile:

Though it feels unnatural to edit on the right and have the preview on the left.
But that's probably just me. :slightly_smiling_face:

Btw. for the places where it is already present it is not just about discoverability, much more usability. You need two clicks to switch between edit and preview mode.

Interesting! We're definitely thinking about making it a bit easier to see the commit history of a PR - we use the atomic unit of "versions" for updates to a PR, and reviews are often left on the most up-to-date version. But yeah I see what you're getting at here

+1, my team mates come from a culture of having well formed individual commits, which is philosophically aligned with stacked diffs, but the lack of this feature means they feel like they have to go back to github to follow their style of code review.

:grin:
<https://graphite-community.slack.com/archives/C02DRNZELUU/p1684252163177009>

it's available if you click + drag down lines, like on Github

Ah, thanks.
It's not "like on GitHub" though, but "like one way to do it on GitHub" that I was not aware of. :smile:
On GitHub I click on the first line, then Shift+Click on the last line to select multiple lines and then create a multi-line comment by clicking on the plus button.

I was neither aware that you can select multiple lines by d&amp;d on the line number, nor that you can comment on multiple lines by d&amp;d on the plus button.

Additionally, if a "suggested code change" is in a "stale" box in the PR details on Graphite, it is even worse. Then only the new version is shown with default background and not even a diff:

We’ve talked about building this - Cc <@U04AP0M9AES>

These comments are part of why I don't merge via the Graphite interface. They don't carry unique information, and come across as just trying to get a link to "Graphite" in front of more people (at our cost by lowering the signal/noise ratio).

By contrast, the Graphite comments that show the stack info are wonderful cause they carry unique and useful information.

thank you for this feedback! for context, we built these comments to let you know what's happening with your merge but y'all are right that this is only really useful to the author -- we'll explore ways to make this less noisy and more actionable :slightly_smiling_face: 

a side note~ as a workaround for now, graphite slack notifications will ignore these comments!

BTW, I'm not actually accusing y'all of growth hacking :grimacing: . I'm just sharing the feeling that non-Graphite users on my team have had around things like this. Thank you all for always being receptive :slightly_smiling_face:

The reason we added these is to keep visibility high for what the jobs that we run are doing — especially the rebase one — we were concerned that folks would be concerned by the opaque "force pushed this branch" comment, and the rationale behind the merge one is that without it, it looks like the user themself pressed merge on GH (not that it was done by an external application).

Both reasons make total sense for getting started with Graphite but using it heavily and merging multiple branches a day it becomes annoying.
Our entire team uses Graphite and we don't care which tool someone used to merge or rebase a branch. We trust each other and for that reason it seems unnecessary to us.

Maybe this can be a setting, defaulting either way.

It should be easy enough for us to add a setting here.  I think that's the first change we'll make!

Believe me, we want this too! We've been working super hard on infrastructure that allows this to be possible — calculating this for every PR in your inbox at once is non-trivial

(from bottom of the PR page, there's a list of shortcuts there)

Nope, mind the bold word :slightly_smiling_face:

Those go through all threads whether open or not

It's great to also have those, I want the others additionally :slightly_smiling_face:

Yes, I intentionally took the same working you use in the dashboard to make it clear :smile:

(i've worked here only 1 month so i'm not familiar w/ all the terms)

<@U02RREE9GKH> would this be an easy lift?

i'm probs gonna hold off on using the merge [queue] features in graphite so as to spare the noise to my colleagues, but i'd love to just disable these for my repo! or fold them into the existing graphite comment that shows the stack

Checking with the team to see what we can do here!

hiya <@U02RREE9GKH>! got another ask for this from the team; is this possible on your end?

hi <@U03RGJEDWH5>, sorry for the delay. I have a few questions to help make sure we solve this correctly:
1. is it just that specific comment above you'd like to disable ("X merged pull request"), or is it also other comments?
2. are there any comments you _do_ find helpful and would want to make sure we keep?
3. finally, sounds like just updating a comment is enough, so IIUC you'd like to have the status clear, but it's not necessary to broadcast _any_ of them to the team as it happens: is that right? 

1. i think there's also a "X queued this stack to merge" message that my colleague has complained of (i don't see these myself as i try to stay within graphite)
2. i think the "fixed" comment that draws a picture of the stack for github users is great for making clear to github users that the PR is part of a stack (and is helpful for navigating across the stack if i find myself in github)
3. aye the messages need not be broadcast to the team, but perhaps including these status messages as part of the aforementioned "stack" comment would be nice!

thank you for the detailed feedback! going to discuss this with the team a bit and see what exact improvements to make

Heya <@U04J1Q5QSER> what's the latest here?

hey Lowell, <@U03Q89DJPL4> was looking into options here and might have an update on where he's at

For the short-term, we have switch the merge comments to be a single comment that we update instead of a series of comments. We are hoping that will reduce some of the noise.

Great call - Cc <@U02E95J4648> seems like an easy fix?

On this, open AI just released the newer gpt-3.5turbo 16k model. Could make summarising easier :slightly_smiling_face:
<https://openai.com/blog/function-calling-and-other-api-updates>

Hi there! Sorry that it's been confusing - can I ask what specifically is causing issues?

Example: I just typed `git branch down` when I meant `gt branch down` and this has an unwanted side effect :disappointed:

Yep, what Steve said. Also I keep creating a branch named `checkout` because I accidentally ran `git branch checkout develop`.

Also one of our colleagues used `gt push` thinking it was Graphite command and messed up his stack somehow.

Ah so the `git branch down` and `git branch checkout develop` don't sound like git passthrough issues necessarily, but instead using `git` where `gt` should be used

What I'd suggest here is using the `gt` shortcuts (see <https://graphite.dev/docs/command-reference|this command reference>) to reduce overlap between `git` and `gt` commands such that if you were to accidentally use `git` again, it wouldn't be destructive. (In these cases, you could use `gt bd` for `gt branch down` and `gt bco` for `gt branch checkout`) A nice side effect is that it also speeds up your workflow so you don't have to type such long key words :')

The `gt push` one is a little tough - we're planning some overarching changes to the CLI that should make it less confusing when interacting with git commands in general!

Yeah! We are planning to show this (we actually already track it)

Aw man, sorry this happened! Taking note of it
cc <@U02RREE9GKH> for feedback here

Sorry to make the change here - syncing every repo in every org for every Graphite user in near-real-time was killing performance for all users (we expect to see *significant* perf improvements for all users once the change rolls out) and causing us to spend unsustainable amounts on RDS every month. After the change happens you’ll still get notifications for PRs in all repos, and we’re adding a prompt to select new repos where you’ve created a PR or been tagged as a reviewer/in a comment etc as you suggested.

I like the idea of prompting users in an org to add new repos as they’re created as well

Seconding this - <@U02NXEUP3G8> we found for users in orgs with thousands (or tens of thousands) of repos, we couldn’t provide a positive “all repos” experience. By having users specifically indicate which repos they’re working in, we can provide a much faster syncing experience. Agreed there’s room to improve the UX of how these repos are selected

Screenshot 2023-06-23 at 10.40.19 PM.png

Yeah, I get it. Could you maybe implement it as a limit rather than a blanket disabling? Like if there are sub 100 repos, allow that option? I imagine most startups will fall under that umbrella. If not, I think having the UI show as `44/45` here instead of just `44` would go a long way towards making the problem obvious. Right now, I have to scroll through dozens of checkmarks to find if anything is missing.