Show HN: Graphite – Stacked Diffs on GitHub

TLDR; Graphite enables a git workflow called “stacking” - the fastest way to develop and ship code, which many large tech companies have been using for years. Graphite makes stacking available to anyone with a GitHub account.

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

159 points | by tomasreimers 597 days ago

28 comments

  • DandyDev 597 days ago
    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?

    • Xiulung 597 days ago
      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)

    • thecarissa 597 days ago
      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 :)

      • DandyDev 597 days ago
        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.

        • thecarissa 597 days ago
          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 :)
          • DandyDev 597 days ago
            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?
            • nyy 597 days ago
              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!

            • Xiulung 597 days ago
              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.

        • morgante 597 days ago
          > 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?

  • jamesmishra 597 days ago
    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.
    • tomasreimers 597 days ago
      Thank you! Yes, we've tried really hard to take the best parts of Phabricator and incorporate it into the product :)
  • juliennakache 597 days ago
    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.

    • kdottt 597 days ago
      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!

    • Xiulung 597 days ago
      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

      • juliennakache 587 days ago
        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!

  • Nezteb 597 days ago
    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.
    • thecarissa 597 days ago
      It's on our radar! As we grow our team more I hope we can support this :)
  • njaremko 597 days ago
    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!

    • Xiulung 597 days ago
      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)

      • njaremko 597 days ago
        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?
        • Xiulung 597 days ago
          Yep, our app signing the commits would mean requiring your org to approve the app as "someone" who can contribute to the repo
        • amtamt 597 days ago
          then why not let them generate the key itself?
          • njaremko 597 days ago
            So I can revoke the key if I need to (my understanding is that you need the private key for that)
      • joshka 596 days ago
        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.
  • satvikpendem 597 days ago
    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!
    • tomasreimers 597 days ago
      Ha! Thank you! It was great meeting you too
  • timvdalen 597 days ago
    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.

    • kdottt 597 days ago
      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...

      • timvdalen 597 days ago
        Will drop a line the next time I hit it!
    • jacobegold 597 days ago
      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.

      • timvdalen 597 days ago
        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.

  • carlgao 597 days ago
    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.

  • Kdmalloch 597 days ago
    Such a good idea, and such a good product. Congrats on the launch!
    • Xiulung 597 days ago
      Thanks for the support @kdmalloch!

      - Xiulung (UX @ Graphite)

  • bovermyer 597 days ago
    I was very confused at first how a timeseries database would be used in a git workflow.
  • xavhan 597 days ago
    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
    • thecarissa 597 days ago
      Glad to hear that! Thanks for being a part of the community :)
  • baq 597 days ago
    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?
    • gugagore 597 days ago
      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.

  • geekster777 597 days ago
    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.
  • zurawiki 597 days ago
    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

    • tragic95 597 days ago
      Agree. After leaving FB, I was surprised to see no open source tool recreate its stacking workflow.

      Graphite is a god send in my post FB career!

    • Xiulung 597 days ago
      Thanks for the support @zurawiki

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

  • jpochtar 597 days ago
    Love to see this! I miss stacked diffs from working at FB— Graphite looks like the best way to be productive outside FAANG internal tooling
    • kdottt 597 days ago
      Hell yeah, that's the idea haha! Bringing the internal super secret FAANG workflows to the world :)
  • atpgenerator 597 days ago
    I’ve tired the CLI, but couldn’t get into it. I’ll have to try the VSCode extension and give it another shot
    • fosterfriends 597 days ago
      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!
  • ikornaselur 597 days ago
    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?

    • Xiulung 597 days ago
      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?

  • Xiulung 597 days ago
    Excited to see what comes next!
  • olafura 597 days ago
    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
    • fosterfriends 597 days ago
      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?

    • tomasreimers 597 days ago
      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 :)

  • AirFuel 597 days ago
    Simple but very compelling... Congrats to the Graphite team
  • bilalq 597 days ago
    I've been using Graphite since November 2021 and love it. Aside from stacking, their dashboard is also a huge improvement over Github's.
  • astuyvenberg 597 days ago
    Congrats on the launch, this looks great!
    • Xiulung 597 days ago
      Thank you for your support!

      -Xiulung (UX @ Graphite)

  • Apreche 597 days ago
    Going to keep my eye on this one.
  • anvisha 597 days ago
    Exciting launch, congrats!
  • daniel_sushil 597 days ago
    Great to see new players in this space. Congrats on the launch!
  • bgenchel 597 days ago
    congrats on the launch! excited to give it a go
  • sond813 597 days ago
    Congrats on the launch!
  • tr_user 597 days ago
    is this in opposition to trunk based development?
    • nyy 597 days ago
      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.