Graphite Community

Thanks for the request! <@U02DGG322G5> is thinking about this for our upcoming roadmap :slightly_smiling_face:

Yep, I implemented that when the CLI was still open source.
Unfortunately it no longer is. :disappointed:

+1 for this. I have to open the graphite link, menu, copy link to github, paste in a new tab everytime i open a pr right now

<@U067X6LD7N1> you might be interested in
<https://www.linen.dev/s/graphite/t/12313428/how-do-i-get-from-the-dashboard-to-the-github-view-of-the-pr#8a31cf5c-2074-48eb-8f03-5cd43d31bc7c> :slightly_smiling_face:

if you want to avoid the menu step, pressing `L G` on the pr page will copy a link to github

I appreciate both of the tips

But I don't want to go to graphite to go to github.

I just wanna to go from CLI to github PR with no extra steps.

Thanks for the tip, but I don't have gh cli installed and don't want to install it.

I just want to use graphite CLI to open the gh PR.

Me too, but we have to wait until they finally hopefully implement it

Or re-open source the cli, then I make my customization again

I use `gh pr view -w` myself when I absolutely need to get to GitHub.  We tend to only provide links to GitHub when necessary as a general pattern — this thread has some background on the philosophy: <https://www.linen.dev/s/graphite/t/10751389/would-be-nice-to-have-a-fast-way-to-get-from-graphite-review#5a84ace5-68c8-45f9-adf1-8eefefaf3743>

I acknowledge the desire to keep gh out of `gt`, but I also think it's important to consider that you frame Graphite as an opt-in tool that doesn't force the whole process on the whole team.

Or, more literally: sometimes I still have to work in old-style integration branches and need to get to github to deal with branches merging into those integration branches.

I would appreciate being able to have 1 way to open PRs — on graphite _or_ github: `gt pr` or `gt pr --github`

I *love* using `gt` and i just wanna use it more :slightly_smiling_face:

I understand and appreciate the desire to have a single tool that allows you to navigate to either — from our perspective it makes sense that the Graphite CLI would link to the PR on Graphite and the GitHub CLI would link to the PR on GitHub — that feels like the right amount of opt-in to us.

To draw a more clear model, perhaps it's that the data source is the same, and the workflow tooling leads down divergent paths. I think we want to keep that line as clear as possible — as we are already forced to blur it in other places.

While I'd still appreciate adding a mechanism within `gt pr` to get to my github PR — I think "if you want to use github, you can use `gh` alongside `gt`" is a reasonable response.

I'd encourage you to reconsider our request, but can accept that it's not something you're planning to do for the time being :shrug:

I appreciate the responses regardless — thanks.

<@U067Z2XQAJ0> Here's a list of solutions... if you find any others, or make more yourself, feel free to add! <https://github.com/benjaffe/graphite-plus-plus>

<@U05447TKZKP> added yours in there too, btw

Hi there! We're planning on adding merge settings soon for this reason - stay tuned!

hi Reshef, sorry you're experiencing this

one question: does your repo have `Automatically delete head branches` enabled? this helps reduce the chance of that problem (see our relatively new <https://graphite.dev/docs/github-configuration-guidelines#general-recommendations|github config docs here>): I'm curious if you're hitting problems when it's enabled

We did not, but we do now :slightly_smiling_face: Thanks!

Next time I merge, I'll try it out and see if it gets fixed.

Feedback: It's too "easy" to set up Graphite without seeing these docs. The nux to first-dashboard view is very quick, which is nice, but I'd have liked for all these recommended settings to be shown to me (as a GH org admin) in the first setup of Graphite.

Settings I've had to change since the GH defaults don't play nice with Graphite, which could be great to show in a new-repo wizard:
• disable merge commits/require linear history (to merged PRs having multiple parents)
• default to squash-merge
• Automatically delete head branches

this is really good feedback especially as we're thinking a lot around the new user experience at the moment. thanks so much for sharing!!

My main issue is that if i want to keep certain fields related to my own PRs open, the other stuff related to review requests is always below the fold

`gt log` will tell you if CI is currently running, but we don't currently support a summary of which checks

gt log does not give any info like that at the moment. Do I need to add a particular flag?

`gt log` outputs the current mergeability status of the PR. If it is blocked on CI running, it will tell you

image.png

ah right, but not if the CI is currently running tests for example:

My use case something like - wait for the long running tests to pass and then convert the PR from draft to a published version

But it's not a deal breaker :wink: thanks!

Ah no, that use case is not currently supported

i believe this is on our roadmap, thanks for +1 ing it!

Related, I think, since you need to have a link to the comment available to do this:

I would love if these notifications would auto-scroll to the comment like github's slack notifications did!

CleanShot 2023-12-07 at 11.04.10@2x.png

A grid/ multiple column ability would also answer my request <https://graphite-community.slack.com/archives/C02DRNZELUU/p1701819774904299|here> (my stuff on one side, my reviews on another side)

It would be a nice feature for free tier users to be able to see a list of open stacks, it’s frustrating to get a warning that there are 7 stacks open and have to manually go through all our PRs to figure out which stacks are still open

one question i'd have is "how would we know whether you mean for the single commit title to map 1:1 with the PR title?"

(i know sometimes i have a commit title that doesn't match the ultimate PR title)

if it was an explicit flag to `gt submit` (like `--update-title`) it would be less of an issue tho!

i've thought about this a lot, especially while i've been working on the vscode extension. more coming here — i think we'll build some model around this there and then backport it to the cli

Thank you!!!! Is there any chance Chris would be able to chat with us for ~15 min on his experience with the new UI some time this week? Feel free to DM :') would be awesome to talk about the feedback he has, curious to know more about the "harder to push code to the first PR in a stack of N" bit and how we can make that better

Also as you guys use the new extension - double clicking on a branch checks it out!! (might reduce some of the mouse up and down movement)

He would be willing to chat - should I add him to this server?

~That would be great! He can join via <https://graphite-community.slack.com/ssb/redirect>~

i dont know if that link works as an invite -- <http://join.slack.com/t/graphite-community/shared_invite/zt-1as9rdo7r-pYmEZzt6M1EhTkvJFNhsnQ|join.slack.com/t/graphite-community/shared_invite/zt-1as9rdo7r-pYmEZzt6M1EhTkvJFNhsnQ>

yes, I would be willing to chat to make this better for everyone

A related idea is to let us specify an emoji for a branch. That'd make it so much easier to track what's what. Right now I have a lot of this:

I know it might seem like an out-there idea... but these are both really just requests for better metadata to make tracking our branches easier, visually or otherwise.

love your general thinking here! both ideas seem cool pending fuller design thinking :slightly_smiling_face:

you can still use it in a pane if you want, although we're currently optimizing for sidebar as that seems to be how the majority of folks like to use it

it would be helpful if graphite can show the "branch is out-of-date with the base branch" ui the UI. granted, we haven't enabled merge queues yet on our end which fixes this.

Hmmm, where would you like to see these PRs? The inbox? Notifs? Slack?

For those that use slack I reckon that would be a useful place as well, but that is not an option available in this case.

I was hoping to be able to see them in the inbox.

<https://graphite.dev/docs/command-reference#gt-checkout-branch|https://graphite.dev/docs/command-reference#gt-checkout-branch>

I don't think `gt checkout -` works. When I run `git checkout -` it checks out the last branch I was on, I remember not observing the same behavior with `gt`

Ohh I totally spaced and missed the `–` there - you guys are correct I don't believe we have this yet!

or an option to just save at some point? Which would, if you exit at any point after creating at least one new branch, would just add what is left to some temp branch?

or a way to continue where one left off? Not sure if the state is saved somewhere

we do create the commit shas, we can do a better job of surfacing them for folks who want to go spelunking. of course in the longer run I do think we can make a resume feature

i wonder if `git` returns a specific exit code (`&gt; 0`) when hooks fail, so that it is detectable without having to parse raw text output from the error?

I don't think that it does (git is notoriously annoying with exit codes) — but will look into it. We definitely have a lot of ground to cover on better surfacing hooks in general.

maybe it's ok to just pass through the entire error message for any error (and better in general–since the goal seems to be visibility)

if i had to roll the dice, git probably passes the error code through from the hook

something like `gt undo restack` . I want to undo last restack and change my local state to its previos version stack. <https://graphite-community.slack.com/archives/C02ENKC0A9X/p1702327073467819?thread_ts=1702319987.536569&amp;cid=C02ENKC0A9X|useful for the infrequent – but not rare – base rebase>

Hmm it could definitely use a bump in size

Screenshot 2023-12-12 at 2.50.42 PM.png

Good feedback - perhaps we could have a notion of a "needs submit" indicator of some kind

cc <@U02RREE9GKH> we'll keep this in mind as we make more updates

Screenshot 2023-12-12 at 3.37.40 PM.png

definitely something we're planning very soon!

Awesome, figured it was probably on your radar - thanks!

yeah, there's some refactoring we need to do on the page to enable it, as well as fix some outstanding bugs with how we're linking from the Unresolved comments box + add permalinks

is roughly the work

I posted a similar Q <https://graphite-community.slack.com/archives/C02ENKC0A9X/p1702487630424139|here> (no answer yet)

hi both! we're working on updating this - thanks so much for the feedback!

I know that `gt checkout` doesn't pass through to `git checkout`. I would love though if it could be used with the `--ours` / `--theirs` option for resolving rebases, since restacking often ends up in resolving merge conflicts this way

thanks for the feedback Jeff - we hear you and are working on fixing this!

great, thanks! lmk if you implement a way to at least turn off the CI check — we’re seeing red :x:  on all our PRs atm aha :sob:

When using `Merge when ready` with the merge queue it waits with rebasing a pull request until the build has succeeded. This seems like a reasonable conservative choice but it would be nice to be able to tell it to rebase as soon as it sees that the PR is out of date with main so that if all the tests are going to pass it will be ready to merge sooner rather than later (i.e., having to wait for only one set of tests to run instead of two)