Hey DandyDev, our Graphite Free and Team tiers do support our GitHub Enterprise Cloud customers.

If you need GitHub Enterprise Server support (eg. on-prem) then that would require our Graphite Enterprise tier...

Typing this out I realize this is confusing and will reconsider the naming of our tiers.

This is a question we spent a lot of time considering because we want to be sensitive about costs and accessibility for all engineers.

So firstly, we have and will continue to have a free tier where anyone can use Graphite for free and get the benefits of the stacking workflow.

Secondly, we have a lot of companies like Ramp who have seen a real gain in productivity from their team and think that the features and benefits of the Graphite Team tier is worth paying for (you can see our customers and case studies on our website).

Lastly and most pragmatically, we need to ensure we have a sustainable business model because we ultimately want to continue bringing word-class devtool features to all of our users.

We encourage you to sign up and try it out. Hopefully you’ll find that the productivity gain is worth the $1 a day. If not, that’s cool too, hopefully we can continue building and improving our product offering so that you check us out again in the future and change your mind.

- Xiulung (Design @ Graphite)

Yes, we definitely help deal with the pain around rebasing.

In addition, in our code review interface we provide the ability to see and review PRs in the stack context so reviewers can see and understand what the dependencies are, we have the ability to merge a stack (in full or in part) automating the process of any rebases that need to happen between merges, and we also have a merge queue that is stack-aware which makes sure that PRs added to the merge queue are merged in order while ensuring that everything merged into the main branch has passed tests.

Depending on your org's GitHub settings, using stacks can be a pain because the branch protection rules aren't always clear when you're looking at a PR that is stacked indirectly on a protected branch. In those cases, you may find that as you merge your stack in order, additional blockers get added. Graphite helps to show you these requirements ahead of time so that you can make sure your PRs are actually ready to merge before you start merging.

What are some pain points you or your team face?

Thanks for the support @zurawiki

Agreed! We think this is a huge performance boost and why we think any engineer should benefit from stacking!

Thanks for the support @kdmalloch!

- Xiulung (UX @ Graphite)

Hey @njaremko,

Thank you for using Graphite and your support. This is something we're aware of and current thinking around.

Question, if we were to support this by signing commits: Would you want the commit to be signed by the Graphite GitHub App? Or would you prefer for it to be signed by Graphite on behalf of you? Or some other option that we haven't considered?

-Xiulung (UX @ Graphite)

I think letting me give you a gpg private key and you sign commits with that would be ideal. I'm not sure how the app signing commits would work, since it needs to be signed by a member of our org I believe?

Yep, our app signing the commits would mean requiring your org to approve the app as "someone" who can contribute to the repo

then why not let them generate the key itself?

So I can revoke the key if I need to (my understanding is that you need the private key for that)

Signed locally using your GPG key is the correct answer to this (IMO), otherwise you're replacing a one attestation with a much weaker one.

Thank you for your support!

-Xiulung (UX @ Graphite)

Hey @juliennakache UX designer at Graphite here,

All PRs will be shown with the proper draft/open/closed/merged states on GitHub and on Graphite, we do a lot of work to make sure that the real-time status is synced between the two so that you can adopt Graphite without disrupting your team's existing workflow.

Would love to know other pain-points you have around GitHub so that we could make Graphite even better for you and your team

Hi, sorry just seeing this.

What about the comments on commits? Are those all displayed in the Github PR when it's merged, and attached to all the correct lines, even the ones that were made on branches that were rebased?

Thanks!

Excited to see what comes next!