Graphite Community

Screenshot 2023-05-04 at 17.10.08.png

Hi! If you're able to disable the "Dismiss stale pull request approvals when new commits are pushed" branch protection rule on GH that would be the best solution here.

Thanks Jacob!

I’ll run it by the team. I suspect they’ll be against it because this would also mean that one can completely rewrite the PR while keeping the approvals for the old version of it :smiling_imp:

I was hoping that GH exposed some sort of API along with the button, but I wouldn’t be surprised if they kept that to themselves for now. The feature is pretty new.

Sweet please keep us updated, I will be first in line to sign up whenever it's available for anyone to try :slightly_smiling_face:

Ideally it should be in the system keychain

Hey Cat! Thanks for the suggestion - we've just barely started to explore the concept of switching organization views (much like how you switch between workspaces in Slack) for this exact reason!

In the mean time, you should be able to toggle which repositories are visible in your PR inbox. Selecting those that correspond to the orgs you want to hide is a quick solve here

didn't realize this would have a negative effect on some of y'all — will just make it configurable

If there’s not actually a benefit to this change, I suggest it just be reverted

My assumption was that its because if you squash and merge the PR description becomes a commit message

I wanted the change so I could have Vim recognize the file type as that for Git and apply my configurations. :) my original PR made the name configurable but we figured it would not be a negative impact to others. 

As `rebase` is not a `gt` command it is given through to `git`, so this should be supported already, shouldn't it? It will not restack the upstack, but that's why `upstack onto` should be used if you have an upstack.

yeah, I was imagining that it wouldn't a pure pass through, so `gt` could handle restacking. It would augment a command that people might already know.

I guess that would majorly confuse though if you have such hibernate commands. I personally even prefer to use `git` itself for `git` commands.

The docs for graphite said somewhere something like "We want you to think of gt as a complete replacement for the git cli" and that also preceded an explanation that the tool will pass through to git for some commands. I suppose since I'm already quite comfortable with the existing git cli I suppose I would feel better about thinking of `gt` as a replacement tool if I could generally do operations like `gt rebase -i` or `gt rebase --onto` the way that I'm used to except that `gt` would shim those commands to make sure that it can restack branches as needed. As it is you have a new frontend `gt` tool where you have to be cautious to consider that some commands might be direct pass throughs that let you shoot yourself in the foot and it also means that equivalent functionality needs to be placed under a completely different sub command which might not feel as intuitive as the original command. (e.g. need to remember `gt branch edit` is a replacement for `gt rebase -i` and `gt upstack onto` is a replacement for `gt rebase --onto`)

I totally get you.
I just don't agree. :slightly_smiling_face:
I like that `gt` does Graphite stuff and `git` does plain Git stuff where it does exaclty what I want and what I'm used to and not suddenly magic other things.
I personally even don't like the push-through of Git commands.
It's similar to `hub` which was also meant as `git` replacement with additional logic vs. the new and official `gh` which does not proxy `git` but is just a standalone tool for the GitHub stuff.
If I would use the `git` push-through - besides being slower than just using `git` even if just slightly - then I would also always have to keep in mind which Git commands are decorated by Graphite and how and then decide on each command whether I want the plain Git behavior or the decorated one.
But that is of course just my personal opinion. :slightly_smiling_face:

I personally do not like the git pass through, but also had a hard time finding `upstack onto` multiple times this week. For some reason I was looking in `gt stack` instead of upstack 

I was searching for `--onto` in `upstack restack` once :smile:

&gt;  I just don't agree
fwiw I also don't really think that it's the ideal approach either (personally I'd rather have a completely separate cli without passthrough) but it seems like `gt` should either go all in or all out here. Either it augments the standard `git` command line interface and I think it would be good in that case that it would shim standard commands like `git rebase -i` or `git rebase --onto` or else it should be completely standalone, and then it has the freedom to use subcommands that do map back to the standard command line interface in a perhaps more intuitive way.

It just doesn't seem great that the graphite cli can easily trash its own metadata because a lot of commands just pass directly through to git which is unaware of the graphite metadata

if it was a completely separate tool then it seems like it would be easier to create subcommands that naturally pair up with how `git` works but without needing to work exactly the same - e.g. it could have a `gt rebase` command for accessing `gt branch edit` and `gt upstack onto` functionality

Also debatable, I regularly type `git cc` when I really wanted to do `gt cc` :smile:

yeah I was struggling to fight my motor memory for typing `git` when playing with `gt` earlier :slightly_smiling_face:

We've also thought about this — a lot of the reason the commands are still the way they are is momentum to be honest

I guess now, while you're in beta, is the best time to consider options and experiment :slightly_smiling_face:

As another thinking out loud idea, I was wondering if the graphite team have considered storing the `parentBranchRevision` ids directly in a ref (e.g. `.git/refs/branch-metadata/my-branch/parent-base` instead of a json file so that it could integrate with the `--update-refs` feature that's in Git 2.39, so then if people where to use `git rebase --update-refs` (or if they enable updateRefs globally) that could be compatible with graphite?

hello! thanks for this suggestion - we're thinking about revamping the versions view a bit and this is a great idea! cc <@U02DCQ1C0G6>

Ooh thanks for the suggestion! Taking note of it :))

Hi Cameron! Thanks for reaching out - are you dragging mp4 files into the description field, or pasting a link in?

This is for a PR opened by someone else on Github. So I am just viewing the PR description and seeing a link. On GitHub the link is rendered as a video player instead.

Thanks for the info <@U057ZSJRJHH>, for the video you’re trying to preview, what file extension/format is it in?

No file extension present, looks like it’s the format from Github when you drag/drop to upload a video via their UI: `<https://github.com/>&lt;repo&gt;/assets/&lt;id&gt;/&lt;id&gt;`

It sounds like you may already show a video player if the URL is a .mp4, for example? Hopefully there is some way to detect what those GitHub asset URL’s are for, since as far as I know that’s how they handle any videos we upload into the PR description.

Hmm thanks for flagging! Creating a ticket for this now

We are working on it! cc <@U02DGG322G5> and <@U03U29VTJ1H>

Cant wait for the audit to be finished, I want to start using `gt` again for my work :confused:

Please do let me know about status of soc2 compliance.

<@U02E95J4648> is submitting stuff next week I believe :slightly_smiling_face:

Is there any status on the soc compliance?

We are now compliant! cc <@U042CEGKRKM> who can provide the details :slightly_smiling_face:

We’re about to announce our SOC2 Type 1 certification :slightly_smiling_face: blog post is going out in an hour or two

I look forward to the blog post! This is the gating factor for getting many of the engineers in our company to start using Graphite.

:wave: It's June (I waited a whole day to ask :laughing:) Do we have any idea when this will be official so I can continue to push on getting graphite approved in my org?

Hi guys! Our observation window is now closed - our auditors are writing the report :slightly_smiling_face: expect an update here in the next ~2 weeks!

Cc <@U02DGG36CSH> / <@U02DGG322G5> seems like there’s a bug in onboarding?

We're working on improving the onboarding flow this quarter! This definitely sounds a bit confusing, sorry you're running into this

no problem, now that we have the step by step it's way easier for us :sweat_smile:

I had to record the initial onboarding experience to deal with this exact issue — quite a big friction point to get new engineers onboarded onto Graphite sadly

Sorry you guys ran into this - we’re working on an overhaul for onboarding that will address this issue!

image.png

make sure to give me a discount when you guys start charging :stuck_out_tongue:

`R Y` for approving a PR works again! :tada:
Thank you for removing the focus to the review box by detault, that's great!
(next step: `R 1` , `R 2` , `R 3` ... to include a configurable canned review message like "LGTM" or "/didnreadlol" ? :grin: :pleading_face:  )

that would be fun! would the fallback experience viewing it on <http://github.com|github.com> be to just render `:my-custom-emoji-name:` as plaintext?

It actually works in GitHub UI too, no fallback needed.

You can do a bit of markup like `&lt;picture ...&gt;` with a URL to the custom emoji image file and GitHub UI will render it

and is `&lt;picture&gt;` just meant to be `display: inline` with text, as opposed to `&lt;img&gt;`?

```&lt;picture data-single-emoji=":seal-clap:" title=":seal-clap:"&gt;&lt;img class="emoji" width="20" height="auto" src="<https://single-emoji.vercel.app/api/emoji/eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIn0..UXG9W2HoeMxnQpHr.IF9TmzgIP_G4zSbfdjdkW0JypylvtqgrK5lJQTJPqam83fnEsIph0-E7Q91JyWW5lNUDbjZTdRvhfc6PNRzXgSHnaOQLqjeo7bcUb60_juUX_XKp816caLYB1ykacwqk.zXNczqnfQbXYX2zWCiA1Qw>" alt=":seal-clap:" align="absmiddle"&gt;&lt;/picture&gt; ```
Here is an example of how the Single Emoji app linked above does the markup. That apps works in the GitHub UI through a chrome extension.

It does display inline as you would expect an emoji to, rather than a block image.

oh but do you need the Chrome extension to correctly render it?

Nope! Anyone can view it.

The chrome extension is only for posting custom emoji. It provides auto-complete so I can type `:seal-clap:` and see the custom emoji in the suggested list like any other emoji. Then, I believe, when you go to submit the comment it does a find/replace of the text `:seal-clap:` with the markup above

i know companies have gallons of emoji in their Slack instances, depending on the culture
and replicating them to Graphite might be annoying too

would you prefer to just hook up your slack instance to graphite and ingest the custom emoji from there, if that was possible?

(for example Stripe had like… 50,000 custom emoji? and i remember we wanted them on PRs haha)

that might save us building an entire UI identical to Slack's emoji upload UI

(it ties the feature to slack though which is a minus)

&gt; would you prefer to just hook up your slack instance to graphite and ingest the custom emoji from there, if that was possible?
Ya I was thinking it would be an automatic ingestion when I first installed the Graphite Slack app. Could be something I toggle on only if desired, or choose which emoji to ingest if there are that many to worry about. My company isn’t that big so not a huge issue for us to sync everything.

<https://threads.com> it is a Slack replacement

No threads integration right now :disappointed:

Yeah, couldn’t find one, so, no plan to create one either? Is the Slack integration source code open? Maybe I can help create one based on that

The problem is, that you have to remember the name for the current project, and there is no convenient abbreviation.
You could also use `gt bco &lt;upmost branch&gt;`, yet there is `gt bt`.
You could also use `gt bco &lt;bottommost branch&gt;`, yet there is `gt bb`.
As soon as you have multiple branch-off points from the trunk branch, I find it quite common needing to be on the trunk branch to restack and resubmit the whole tree after there is an incoming update.

which points to `<https://github.com/codespaces/new/org/repo/pull/XXXX?resume=1>`

Hey <@U045W8WMUN5>! Been a long time since we've heard from you :')
Transparently this isn't on the roadmap right now, but I'll bring it up with the notifs team and see what they think!

Transparency is always good, thank you! And pretty much anything would help a ton here -- even just the ability to exclude comments that include a given string would be enough.

Ah yeah we have a todo to add a tooltip here! This _should_ be showing the CI status for your PRs

Hm strange - has this always been the case?

all of the PRs that I have in my dashboard have that

Ah ok yeah we have an issue with broken CI status on our PR inbox right now - I'll follow up in this thread once it's resolved! thanks for flagging :slightly_smiling_face:

Oh this is really odd, I haven't seen ligatures in our diffs before - we'll take a look at what's going on here!

Ah so the `fira code` font has ligatures and we currently don't offer a way to disable them - in the mean time if they really bother you I'd suggest switching code display fonts!

You can change your settings here: <https://app.graphite.dev/settings/code-style>

Will take note of it :slightly_smiling_face:

i'd love to see all 9 of the comments in my graphite slack channel[1], with a separate URL for each one! and some context would be great too, like if the comment from someone else is in response to a comment i left, i'd like to be shown the comment i left so i know what their comment is about

i followed the <https://app.graphite.dev/github/pr/Lumen-Energy/roofs/4187/Reify-the-Org-Org-connections?utm_source=gt-slack-notif|URL> and all i see is this one comment[2] (twice!), but when i scroll through the whole PR page i can see all the other comments.

i feel sad that at this point the emails from github are a more reliable notification processing flow for me :confused:

you're going to be very happy about what <@U04HQKF7TSN> is working on :slightly_smiling_face:

If you are a keyboard shortcut kind of person, you can use `s` to open that and then arrow keys to move up and down.

it would be helpful to have that be more discoverable still!

fwiw, i was looking on the right pane bc that's where a lot of controls live

btw i've been using `s` regularly now, now that i know about that trick

we’re actively thinking about how to make these kinds of controls more discoverable!

in the meantime, try hitting `?` to see the full list of keyboard shortcuts :slightly_smiling_face:

Definitely! I know this was flagged to us when it first came out, i’ll check on the status of it in our roadmap next week

it's on my radar as part of my big comment refactors coming up to at least fix it so the comments don't go onto line 1 when someone leaves one in the github UI

we can chat next week about adding it into the comment workstream

That would be more like `git show`
I only to know what files changed.

Not as of right now, but we're planning some improvements to the GitHub stack comment in general!

Does that mean something like this would be included in those improvements? Or that this would be unnecessary given those improvements?

I agree with <@U0558AHEWDS> on this point :slightly_smiling_face: