Graphite Community

At the very least, if you presented it as `X`/`Y` repos in the org or something that would be better

It'd be neat if "Merge when ready" expires after some amount of time. Setting a PR to merge when ready feels like a time bomb if the PR doesn't get merged for a long time... maybe people put off reviewing, and by the time it's approved, it functionally conflicts with code that's landed in the interim. (By the way, I'm assuming that if everything is green and I'm waiting for a reviewer to stamp it, `merge when ready` will merge when the PR is approved... I haven't seen it happen yet, so LMK if my understanding is incorrect)

Screenshot 2023-06-23 at 8.51.47 AM.png

Screenshot 2023-06-23 at 8.48.10 AM.png

Ooh thanks for the request - we've been meaning to make some updates to the stack viz!

Sure thing. If I may expand on it, it would be awesome to have the entire row change color slightly rather than just the marker on the left

Thanks for the feedback! Makes a lot of sense. Few questions:
&gt; •  the ability to add and remove sections on the insights page
What do you mean by sections here?

&gt; • Would like the ability to visualize PR creation by user (PRs merged is a proxy for this, but not completely accurate since anyone can merge anyone else’s PR)
To be clear, when we show PRs merged, it's based on who the author of the PR was, not based on who clicked the merge button. Does that address your concerns?

&gt; • Would like the ability to visualize lines of code created by user, this can be a better metric for productivity than simple PRs, since different devs have different habits on PR size and structure
Fair, I think longer term we should just allow visualization of whatever metric we have.

&gt; • Would like to see average PR size
Good idea, I'll see how easy it is to add this.

&gt; Perhaps adding the ability to create custom queries would be a better choice than pre aggregated data. Similar to the review page where I can create different sections with custom queries.
The concern here is performance. The pre-aggregation allows super snappy queries regardless of the size of the org.

Screenshot 2023-06-26 at 12.01.24 PM.png

1. By sections I mean any independent block shown in this UI, like: Total PRs merged, PRs merged per eng, etc

2. If the graph of “PRs merged” is PRs authored by that individual, then yes, this gives me what I want, although perhaps the name could be changed to make it clear (or add a footnote), not to confuse it with PR where that user simply clicked the Merge button.

I'm also looking for this. On the graphite website, I found a sort of <https://graphite.dev/docs/the-graphite-workflow#using-a-feature-branch-workflow|manifesto against using feature branches>. It lists reasons why this is unwieldy. OK, but many people can't or don't want to switch. There are also benefits to this workflow.

It'd be great if we can get all the benefits of stacking, inside a feature branch, including when the feature branch needs to be rebased. Then when the feature branch is done, we can create a final PR that merges the branch into `main` with a merge commit.

I feel like I'm currently fighting the tooling to get this workflow

Would be nice if  pull request bodies were all conglomerated into one big combined PR body when PRs in a stack are squashed. It's useful to have all those old descriptions, even after squashing.

When I was working at Facebook, employees had super new phones, so nobody experienced perf issues with the app. For a while they had a mandatory program where you had to use a degraded version of Facebook to improve empathy with users who have underpowered phones. It was annoying, but it was amazing at driving perf improvements for the majority of users.

I wonder if there's an analogue here for new users. I love keyboard shortcuts, but it's taken me months to get `Shift - Up/Down` into my fingers. I'm guessing Graphite employees are super fast with keyboard shortcuts. I wonder if it'd be helpful to have an internal new user dogfooding program, which could disable keyboard shortcuts occasionally (or maybe force re-onboarding), as a forcing function to get internal employees to understand what Graphite is like as a new user.

I thought of this because many of my issues with comments recently would have been vastly mitigated if I had those keyboard shortcuts in my fingers. The issue with replies not showing up, for example... I could have just `Shift-Down` a bunch to check everything instead of scrolling through the entire review every time.

Y'all do an excellent job of surfacing shortcuts, and I use `et`, `ed`, etc all the time. But despite the shortcuts being listed at the bottom of every review page, I hadn't connected the dots until now. :upside_down_face:

All that to say, forcing Graphite employees (who are likely power users) to sometimes interact with Graphite in less efficient ways might help prioritize usability tasks that will affect a large portion of your users... in particular, new users (likely the ones you most care about as you're growing)

thank you, this is really good feedback! we’re thinking about how we can both improve discoverability for these advanced features and also make the interface more approachable and usable for new users :slightly_smiling_face:

i like this idea and we’ll definitely consider it internally to help build empathy for the latter case, but please continue giving us feedback about what’s difficult/not discoverable — unfortunately, getting the team to _re-learn_ how to use graphite is hard so we really appreciate your help identifying the most painful parts of the experience and where we can do to better support your day-to-day workflow!

Screenshot 2023-06-29 at 2.22.49 PM.png

that doesn’t always show up for me. when it does, it still shows a side-by-side diff view. i’d like to just look at the file, perhaps in github (but the only buttons available are to copy to path)

thanks for following up. just re-evaluating after the pricing email. happy to chat further in DM

got it! we’re considering what the best way is to support this workflow, either natively or by linking out to github, so this feedback is super useful :slightly_smiling_face:

cc <@U02DGFZ1H0D> for viz

You can hover on it to see distinct values (in case you weren't already aware)

A "High Contrast" theme :art: in line with GitHub's light high contrast mode (see e.g. <https://github.com/primer/github-vscode-theme>)

nice! fyi — i believe there is still one open issue where having multiple graphite tabs open at once can lead to infinite loading (arc’s tab suspension preventing an indexdb lock from being released)

I'm using a pinned tab for graphite and it seems to do the trick (as pinned tabs are not supposed to be suspended?)
We'll see!

makes sense! let us know if you run into any issues 

image.png

This message contains interactive elements.

oof… do you have multiple graphite tabs open at once? clicking into each of them should fix the locking issue

it's OK, I relaunched Arc. It's the easiest solution when it happens :grin:

Indeed, seems fully fixed! Thank you so much!

That sounds like horrible idea tbh. gt must not change any other directory than where I invoke it

Agreed that it shouldn't do that, since it'd be unexpected behavior. But it could do the check and prompt you, or at the least, warn you that you're about to step into a hole.

arguably, it might not be _that_ unexpected for a someone using worktrees, but i agree a prompt would be nice

Oh sorry, I mean the Graphite interoperability with worktrees being weird could be unexpected for a worktrees user who starts using Graphite.

I'd like to have my PR content to be pre-filled with the content of the commits in that stack, so that I can create the PR message by reshuffling the commit messages. It could be an additional option like when we have to choose which template to use for the PR.

:wave: Just stumbled on <https://github.com/withgraphite/homebrew-tap/pull/3> and I think it's a great idea, so I'm submitting it as a feature request! I guess the request is just to merge this pull request, assuming it works correctly.

This should be the case, is clicking viewed not collapsing the file for you?

hmm, it did just now. it's been intermittent for me on firefox. if it happens again that it doesn't collapse,  i'll see if i can share any more details in <#C02DRNRA9RA|bug-reports>!

Screen Recording 2023-07-13 at 11.31.18.mov

just ran into this issue again. latest firefox on macos. no errors in the browser console.

it works on other files in the same PR -- it's specifically this one that doesn't expand/collapse when clicking "viewed". not sure if it's helpful but it's the first file in the PR that doesn't work.

Thanks for flagging - I believe we've seen this issue in the past! We'll investigate

Yes, I'm actively working on this right now. I expect it to be ready soon.

Review response time = median(review time - review request time) for the user in question as a reviewer

Wait till till first review = first review time - publish time for the user in question as author

But overall I agree, we should consider adding this stuff to docs <@U04K5N14V9B>

Does that take into account rerequesting reviews? If so, does it double-count?

And docs is great, but colocating explanatory text is better IMO :smile:

&gt; Does that take into account rerequesting reviews? If so, does it double-count?
Yes, it takes into account review time - request time, regardless of whether it is the first request or not. I'm not sure if I would call that double counting.

Ah yeah, bad choice of words. I guess I mean if someone asks a question, I answer it and rerequest, they ask another qustion, I anser it and rerequest, etc... that pulls down the stats. But I don't see a better way to do it.

Yeah maybe a tooltip or an info icon makes sense here, will look into it!

totally agreed that LOC isn't a particularly useful metric to compare productivity

that said, we include the statistic here because it may be interesting or valuable in some specific instances

we could consider adding some recommendations around how these metrics should be read and used though!



heard on the colors piece, that's something ill look into soon!

re finding names on the graph -- not quite what you're looking for but have you tried hovering over the lines themselves? there should be a tooltip that shows who corresponds to each one

Ah yes, that definitely helps! Although this part is pretty hard :eyeglasses: :face_with_spiral_eyes:

This is pretty low-pri though IMO... it's very functional, especially with more colors

This should be reasonably easy to change, will look into it!

"Open in VSCode" is nice, but seems a bit flimsy - its not super reliable when opening files in different branches (that might not exist on your dev machine yet). What would be more useful for us is "Open PR in <http://vscode.dev|vscode.dev>" that can be done by just using this url format: `<https://vscode.dev/github/ORG/REPO_NAME/pull/PR_NUMBER>`

For what it's worth, neither Notion nor Slack have RSS feeds for their changelogs, so you'll be ahead of two giants in this regard :smile:

<@U04K5N14V9B> Did y'all add an RSS feed to your blog yet? I didn't see one when I checked yesterday. I'm enjoying the content, by the way!

Are these blue bars in the Graphite diff what you’re referring to?

I believe we've only implemented this for some languages, seems like we need to add GQL — cc <@U047KHH8JH3>

Thanks for the feedback, will look into if!

To be clear this is for .graphql files? Or do you also see it missing in other places

Screenshot 2023-07-12 at 11.53.04 AM.png

I see it as missing in TypeScript and TSX files as well.

Screenshot 2023-07-12 at 11.56.29 AM.png

Ah this could be a different in our UI - if the header is identical to the previous chunk, i.e., it is in the same definition, then we don’t show it twice - maybe that’s what’s happening here?

TypeScript should definitely work FWIW - so if that’s not the case I’ll look into it!

<@U047KHH8JH3> Nope, it’s not showing the header at all anywhere. And the contents of the header are within hidden lines.

Do you maybe have this behind a feature flag that hasn’t rolled out everywhere?

Huh, I don’t believe so - can you MD me the PR number? Thanks! Also cc: <@U04AP0M9AES> for the rollout

hey <@U02NXEUP3G8>! you’re right — we did have a feature flag that was not fully rolled out, preventing you from seeing these context lines :man-facepalming:

i’ve got that fixed now so you should be able to see them soon! sorry for the miscommunication here

separately, like ziyao said, our context lines work a bit differently (hopefully better!) from GitHub’s so we’d love to get your feedback on them!

and definitely try out `Expand to definition` by clicking on the function header itself :wink:

Does this only affect PRs submitted after you rolled out the feature flag? I’m still just seeing `X lines hidden`.

hmmm it should now be visible for all `javascript/typescript`, `python`, `java` and `go` files — mind sharing an example if you’re still not seeing them? and separately, we’re looking at adding support for more languages so please let us know which other ones you’d like to see!

Hi <@U04667BD9U4>! Thanks for reaching out and for your feedback. I’d love to hear more about your particular workflow and use case for commit signing. Feel free to <https://calendly.com/carissa-graphite/graphite-for-teams|grab some time on my calendar> here if you’re open to it!

+1 to signed commits, or essentially some way to be confident that the code which is getting merged is actually from my team

+1 to this. We can't really use the stack merge button without it :confused:

Thanks for the feedback all! We’re adding it to our feature request list :slightly_smiling_face:

Update here - this is probably coming in the next month! We are testing this feature internally. Stay tuned for our product update emails!

Screenshot 2023-10-18 at 6.10.12 PM.png

Hey folks, very excited to announce that we just shipped commit signing! :tada:

You can configure this on the Preferences page: <https://app.graphite.dev/settings/preferences>

Want to say thanks for this. Can finally use the merge queue :heart_eyes:

It'd be pretty cool if the Graphite Slack plugin was open source. I'd definitely consider contributing if it meant being able to filter out messages from bots. :robot_face:

Not in the timeline, but this is a good idea! You're able to collapse them in the code though

Hey <@U04RHFT75N0>! Thanks for flagging, we'll add this to our list of feature requests

Thanks for the suggestion! Noted for future insights updates :')

• Noted on vertical ordering: we've had a long-running task to have this match the output of `gt log` (will happen soon!)
• Interesting request, we actually have GTI (graphite interactive) coming very very soon which will let you manipulate and view a stack from a web UI/in VSCode - might be helpful here!
• Also coming very very soon, one of our engineers just finished the work up for this yesterday and it should be launching shortly!

Thanks!
• :+1: 
• Doesn't necessarily need to be a webpage, that was just the medium that came first to mind!
• :+1: 

^^ the last point is in the CLI actually, not the stack comment - unsure if we'll be able to translate this over to the stack comment as well

right, to avoid editing comments constantly, you'd probably have to use a kind of badge-like system, which seems like a lot of work. So it seems like a feature that would work better within a UI you own (CLI/web UI/VSCode etc)

Will GTI indicate when actions can't be taken because of uncommitted changes? I'm so excited for this!!

May I also request that the PR comment only use horizontal indentation to indicate stack forks and not parent-child relationships along the same stack? So something closer to the stack visualization within Graphite and the CLI than the pyramid of doom it is now. :slightly_smiling_face: