Show HN: Graphite – Stacked Diffs on GitHub
64 comments
Honest question: how did you folks determine your pricing? I totally get that what Graphite offers is valuable and can improve developer productivity. But from where I'm standing, the pricing is disproportionate to the value add.
Github Enterprise - while of course not 1-to-1 comparable - offers so much more functionality for 2/3ds of the cost of Graphite. I'd expect Graphite to cost _less_ than Github Enterprise as it seems it could be positioned more as an add-on to what you get from Github.
Am I missing something?
Github Enterprise - while of course not 1-to-1 comparable - offers so much more functionality for 2/3ds of the cost of Graphite. I'd expect Graphite to cost _less_ than Github Enterprise as it seems it could be positioned more as an add-on to what you get from Github.
Am I missing something?
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)
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)
Thanks for the question! We don't typically compare our pricing to GHE but rather to other similar SaaS tools (check out some merge queue providers - which is just one feature of Graphite). GHE has a very different business model - they keep the per seat price low to charge for compute in CI/CD or upsells into Microsoft Azure. As another counterexample, Superhuman is $30/user/mo for an "add-on" to Gmail (a free product).
Every single feature of Graphite’s workflow is optimized around stacking, including: - Beautiful code review interface - PR inboxd - Stack-aware merge queue - Team insights - Integration with your favorite tools like Slack and VS Code
Graphite is scalable, and is built for professional software development. Give it a try for free to see for yourself :)
Every single feature of Graphite’s workflow is optimized around stacking, including: - Beautiful code review interface - PR inboxd - Stack-aware merge queue - Team insights - Integration with your favorite tools like Slack and VS Code
Graphite is scalable, and is built for professional software development. Give it a try for free to see for yourself :)
Here's the thing: I think it's a bad idea to try it out, because I can already see in the pricing tiers that if I would like Graphite, I cannot afford it for my team because of the pricing structure.
I work for a startup that is less than 3 years old and has ~90 employees of which ~50 are software engineers and data scientists (people writing code). We're VC funded and not profitable yet. When I see a pricing tier called "Enterprise", I do not expect to fall under that tier as a small, young company. But looking at the limits of the Team tier, we would probably not fit under that tier because we have more than 30 repositories. We also use Github Enterprise (cloud version), which puts us in your Enterprise tier as well.
If the Team tier is already $30/user/month, I'm afraid to even learn what the Enterprise tier is like. I guess we're not your target audience and that is okay.
Here is when I would consider paying for your product: remove the repo limit (or make it much bigger) and half the price. That would make it affordable and more in line with the other tools we're paying for.
I work for a startup that is less than 3 years old and has ~90 employees of which ~50 are software engineers and data scientists (people writing code). We're VC funded and not profitable yet. When I see a pricing tier called "Enterprise", I do not expect to fall under that tier as a small, young company. But looking at the limits of the Team tier, we would probably not fit under that tier because we have more than 30 repositories. We also use Github Enterprise (cloud version), which puts us in your Enterprise tier as well.
If the Team tier is already $30/user/month, I'm afraid to even learn what the Enterprise tier is like. I guess we're not your target audience and that is okay.
Here is when I would consider paying for your product: remove the repo limit (or make it much bigger) and half the price. That would make it affordable and more in line with the other tools we're paying for.
Hi there, thanks for the question! One quick clarification - the 30 repository limit is per user (not per org), so I expect you would still fall under the Team tier. I'd encourage you to try Graphite out for free - many companies have already found tons of value out of Graphite and are paying for us now.
Also - we have a little promo code for users from Hacker News - try out HN15 :)
Thanks for the clarification. The limit of 30 repos per user is indeed more reasonable.
The support for Github Enterprise which would necessitate the Enterprise tier, is that referring to all flavors of GH Enterprise or only the on prem version?
That refers only to the on-prem version; we support GitHub enterprise cloud out-of-the-box, even on the free tier.
Hearing about your company size and setup, you're actually in our team plan's sweet spot. If you give it a shot, reach out and let us know what you think!
Hearing about your company size and setup, you're actually in our team plan's sweet spot. If you give it a shot, reach out and let us know what you think!
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.
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.
> We also use Github Enterprise (cloud version), which puts us in your Enterprise tier as well.
Why is this at all surprising? If you're using GitHub Enterprise, why wouldn't you be using the Enterprise tier of other software?
Why is this at all surprising? If you're using GitHub Enterprise, why wouldn't you be using the Enterprise tier of other software?
Graphite and stacked diffs are awesome! I really miss Phabricator from my time at Uber, and I've been sad ever since that nobody had built a superior developer experience based on the same concepts.
Thank you! Yes, we've tried really hard to take the best parts of Phabricator and incorporate it into the product :)
Seems interesting! I've been very unhappy with Github workflow and UI for PRs. It's insane that each time you rebase a PR, you lose all your existing comments on that PR (i.e. they are no longer attached to lines in the UI).
Does anyone know if you need Graphite to see a PR once it's been merged in the Github repo? I'm curious about how locked you in when you start using Graphite.
Does anyone know if you need Graphite to see a PR once it's been merged in the Github repo? I'm curious about how locked you in when you start using Graphite.
Not locked in at all!
Graphite syncs bidirectionally with GitHub so that you can see the same information in realtime across platforms. This also means you can use Graphite even if the rest of your team isn't yet!
Graphite syncs bidirectionally with GitHub so that you can see the same information in realtime across platforms. This also means you can use Graphite even if the rest of your team isn't yet!
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
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!
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!
I've followed Graphite for a while, and I just wish they supported GitLab. I know why they don't, but my current employer uses it and I've got major FOMO.
It's on our radar! As we grow our team more I hope we can support this :)
I've been using this for a few months now, and it's been an absolute joy to use.
One thing that's been a bit annoying: my org enforces signed commits, and when you merge a stack, they sometimes rebase commits internally and lose the code signing, so you end up with an error to merge the rest of the stack.
Aside from that, working with stacks has been great!
One thing that's been a bit annoying: my org enforces signed commits, and when you merge a stack, they sometimes rebase commits internally and lose the code signing, so you end up with an error to merge the rest of the stack.
Aside from that, working with stacks has been great!
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)
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?
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.
Hey Tomas, great to meet you a few months ago in NYC, congrats on the show HN. Graphite is a great tool, hope you're doing well!
Ha! Thank you! It was great meeting you too
I've been using Graphite for a few months now (yay, finally works on cygwin!), and I've been really enjoying it.
The command name change will take some time to get used to, though!
I've run into a bug with 1.0 where it tries to query git for an object (something with ^tree) that it doesn't understand. I think I'm on a high enough git version, but that could be my issue.
The command name change will take some time to get used to, though!
I've run into a bug with 1.0 where it tries to query git for an object (something with ^tree) that it doesn't understand. I think I'm on a high enough git version, but that could be my issue.
Hey Tim! Thanks for being with us since the beta. Would love to help you walk through that git query issue. Might be easier on our community slack if you wanna come chat about it there!
https://join.slack.com/t/graphite-community/shared_invite/zt...
https://join.slack.com/t/graphite-community/shared_invite/zt...
Will drop a line the next time I hit it!
So sorry about that! If you update to the latest version of v1, we added a check to verify your Git version is up to date -- we use a feature from v2.38.
Reach out to me (Jacob Gold) on our Slack Community if you're still seeing this issue. The link's on the Graphite website.
Reach out to me (Jacob Gold) on our Slack Community if you're still seeing this issue. The link's on the Graphite website.
Will do!
While I'm at it, will there be a setting to automatically delete branches after merging (on app.graphite.dev)? Without manually deleting all branches after a merge, `repo sync` (or just `sync` now, I suppose!) doesn't pick up that a branch has been merged.
While I'm at it, will there be a setting to automatically delete branches after merging (on app.graphite.dev)? Without manually deleting all branches after a merge, `repo sync` (or just `sync` now, I suppose!) doesn't pick up that a branch has been merged.
Stacking code changes has been such a game changer that I wouldn't even consider working at a company where this developer workflow doesn't exist. Code reviewing without Graphite is like code reviewing with a typewriter instead of a computer.
If you want to 1. multiply developer velocity 2. attract the best technical talent, use Graphite.
If you want to 1. multiply developer velocity 2. attract the best technical talent, use Graphite.
I was very confused at first how a timeseries database would be used in a git workflow.
Ive been using it since mote than a year and it has become part of my toolbelt.
Especially the cli that allow to seemlessly rebase multiple branches at the same time.
Powerful tool, and nice community
Glad to hear that! Thanks for being a part of the community :)
I’ve tried using git brancheless, git spr and stacked git, but they aren’t sticking in my brain. Does this have a better chance for this interactive rebase and squashed merge user?
The main thing I found to be an improvement is that Graphite maintains all the stacking metadata in git refs. With the other tools, I did not know how to develop a stack across multiple development machines.
I would be happy for someone to prove me wrong and show how, e.g. `git branchless` lets you work on a stack from multiple machines.
I would be happy for someone to prove me wrong and show how, e.g. `git branchless` lets you work on a stack from multiple machines.
Been playing with this as a beta user for a few months. I really like how the cli removes a ton of the footguns I've come to find with git. With Graphite I don't have to think too closely about navigating and reordering branches. It's removed a lot of my fears of "will this command clobber my workspace". The guard rails are up, but you can always drop into git if you need something specific.
Excited to see the progress here on the public launch!
Stacking was a meaningful time-saving as a FAANG sw eng. Excited to see stacking grow within the great tech community
Stacking was a meaningful time-saving as a FAANG sw eng. Excited to see stacking grow within the great tech community
I’ve tired the CLI, but couldn’t get into it. I’ll have to try the VSCode extension and give it another shot
Jacob and Alyssa on the team have been working hard iterating rapidly on the VSCode to make a more convenient and intuitive way to stack changes. Please send us any feedback you have through our site or the community slack, would love to hear your thoughts!
Looks interesting! We already stack PRs by basically having a chain of branches, one on top of each other, that we review separately and merge in order.
What benefit does Graphite provide further?
Main pain point I imagine is dealing with rebases? What else?
What benefit does Graphite provide further?
Main pain point I imagine is dealing with rebases? What else?
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?
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?
Excited to see what comes next!
I don't understand how this is a difference between stacked diffs and feature branches. Github allows you to use feature branches. I can see there might be some convenience with tooling
It's a fair question! There are a lot of perks to splitting up your change into multiple PRs rather than one feature branch. You can parallelize getting reviewed while writing more code. If CI fails, it fails on a more narrowly scoped change and is easier to debug. If something about one of your changes is unmergable, you may still be able to merge in half of your stack, rather than your change being all-or-nothing.
A lot of the benefits remind me of other dag-based workflows, like CI, data pipelines, or build systems. Does that make sense?
A lot of the benefits remind me of other dag-based workflows, like CI, data pipelines, or build systems. Does that make sense?
https://stacking.dev/ has a good summary of this!
tl;dr the difference is a stack is merged partially as it's built out (that reduces merge conflicts, allows you to revert individual parts as found) and a feature branch is long-lived. Hope that helps :)
tl;dr the difference is a stack is merged partially as it's built out (that reduces merge conflicts, allows you to revert individual parts as found) and a feature branch is long-lived. Hope that helps :)
Simple but very compelling... Congrats to the Graphite team
I've been using Graphite since November 2021 and love it. Aside from stacking, their dashboard is also a huge improvement over Github's.
Congrats on the launch, this looks great!
Thank you for your support!
-Xiulung (UX @ Graphite)
-Xiulung (UX @ Graphite)
Going to keep my eye on this one.
Exciting launch, congrats!
Great to see new players in this space. Congrats on the launch!
congrats on the launch! excited to give it a go
Congrats on the launch!
is this in opposition to trunk based development?
Nope, we’re big believers in trunk-based development and see this as a necessary extension of it - when you’re blocked from merging into trunk (e.g. because you’re waiting for your teammates to review your code), we believe you should still be able to continue working on your new feature or refactor, but without continuing to make your PR larger and in turn more time-consuming for your teammates to review.
Stacking makes this all easy by allowing you to make smaller sets of dependent PRs so you can stay unblocked and merge into trunk more often.
Stacking makes this all easy by allowing you to make smaller sets of dependent PRs so you can stay unblocked and merge into trunk more often.
Hi HN!
I’m Tomas, co-founder of graphite.dev, and today we’re launching Graphite after almost two years of development in closed beta. [1] Graphite started as an internal solution to our own problem. When we (engineers from Meta, Google and Airbnb) left our previous roles, we lost access to the internal code review tools we loved. So we built our own.
https://graphite.dev
---
Graphite is how the fastest developers ship code - it’s a developer tool that allows you to create smaller pull requests, stay unblocked, and ship faster with “stacking” (creating a set of dependent pull requests). Stacking [2] allows developers to break up large pull requests (PRs) into smaller ones that can be reviewed & merged independently, while keeping ongoing development unblocked. Engineering best practices at Google advise that a “reasonable” PR be around 100 lines, and recommend splitting PRs in order to achieve this through stacking or other methods. [3]
Unlike other tools like Phabricator, Gerrit, or Sapling, Graphite syncs seamlessly with your GitHub repositories, so that you don’t have to manage any extra infrastructure. This also means that even if your teammates don’t use Graphite yet, you still can.
Here’s what you can expect when you sign in to Graphite with your GitHub account:
(1) First class support for stacking: At its core, Graphite enables “stacking”—a workflow used by engineers at top companies like Meta and Google to create small, dependent sets of pull requests. The Graphite CLI, web app, and VS Code extension all come together to empower engineers to start stacking.
(2) Pull request inbox: You can think of this as your home page on Graphite, where you have full visibility into the status of all your PRs and know what still needs to be done across every repo, author, and stage of review. You can also create custom inboxes that filter PRs on reviewers, authors, labels, CI status, and more.
(3) Streamlined code review interface: Graphite’s pull request page removes tabs and minimizes distractions, with the aim of putting your code front and center. You can use keyboard shortcuts to navigate between files and comments or to move between PRs in your stack. You can also import custom memes and gifs to add some to your reviews too!
(4) AI-powered pull requests: Auto-generate a detailed description for every PR with our OpenAI integration. You can even turn your comments into suggested code changes (coming soon!).
(5) Real-time notifications: Connect Graphite to your Slack workspace to stay up-to-date on review requests, comments threads, merge status, and other activity on your PRs. For smaller PRs, you can leave a review (and even merge) directly from Slack.
(6) Stack-aware merges: Since Graphite is built to support a stacking workflow, it automates the manual work of rebasing PRs when it’s time to merge. You can merge your stacks with one click from the web app, or in a single command from the CLI.
Feel free to take a look at our getting started guide [4] or product tour video [5] for a tutorial on how to get started, and drop your comments to us below!
[1] http://graphite.dev/blog/launch
[2] http://stacking.dev
[3] https://google.github.io/eng-practices/review/developer/small-cls.html
[4] https://graphite.dev/docs/getting-started-with-graphite
[5] https://www.youtube.com/watch?v=sBcd9uopLOY