HN user
yep we do! another big use case for it seems to be big enterprises for their own internal tools - we see this a lot with our largest customers.
but the OSS use case described here is a pretty different case, what OP suggested may still be useful there
Not sure how? Meant this:
The agentic coding tools and review tools I want my team (and myself) to have access to are ones that ones that force an explicit knowledge interview & acquisition process during authoring and involve the engineer more intricately in the whole flow.
Yep. We see this future and are working on exactly what you're talking about (Graphite)
As a Graphite employee, would love this tbh - we love Blacksmith!
Maintained, improved, and integrated.
With more resources than ever. We're building whole platform. That's a lot more than just AI.
Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`
we are a 70 person team, bringing in significant revenue through our product, have widespread usage at massive companies like shopify robinhood etc, this is a MUCH MUCH MUCH different story than supermaven (which I used myself and was sad to see go) which was a tiny team with a super-early product when they got acquired.
everyone is staying on to keep making the graphite product great. we're all excited to have these resources behind us!
stacked prs will only get better from here :) we have an incredible amount of resources to keep improving that part of our product.
we have a big effort in the works to improve web perf! where specifically are you seeing slowness in the app — what flows, what pages, etc?
My ideal is really just a version of `gt sync` and `gt submit` that handle updating the Graphite + Github server-side of things let you use `jj` for everything else, I think it could feel super nice. Probably not as simple as my dreams, but hopefully something we can get to with enough interest!
It's so cool that Git is considering first class change IDs!! That's huge! This sounds similar to what we had at Facebook to track revisions in Phabricator diffs. Curious if anyone knows the best place to read about this?
hell yeah
(views expressed in this comment are my own, not those of graphite)
we have a number of large customers that feel the same way and are fully opted out of anything AI-related.
in my experience, our foremost goal is bring graphite to more people. i have seen many cases where folks get us in the door with diamond and then begin championing stacking which leads to a ton of organic spread that it otherwise may not get.
we have seen a ton more signal that ai is the easier way to get more committed folks in the door than signal that we are losing potential customers over having it as an option. if that were not true, we probably would not have gone in this direction.
i would love for graphite-lovers to make more noise about stacking as well and see no reason it can't happen in parallel - every month i see more and more conversations about stacking happening in the wild, and more and more of them reference us directly!
we still do stacked diffs — it's our bread and butter, and many of our existing customers, some of whom have been with us since the beginning, are finding a ton of value from both diamond comments and chat. i loved working on the CLI, i loved working on chat, and i'm excited to continue building tools that make code review less of a pain.
the core problem that stacked diffs and that adding AI to the PR page solve are the same — code reviews slow devs down and force unnecessary context switching.
stacked prs help you get around this by allowing you to manage your work in way that makes it easier to organize in an author and easier to deal with as a reviewer. AI can help you get around this by making it easier to review PRs when you open the page, and save you the context switch of going back to your editor to make a tweak that a reviewer suggests.
Graphite has always been about shortening the cycle time and reducing the amount of busy work from writing code to getting it merged, and we'll continue building features that speed up that cycle.
the best part is — you can still pay for Graphite, and you don't have to use ANY of our AI features. we're still constantly shipping improvements to our CLI, optimizing our merge queue for our larger enterprise deployments, continually working on making the PR page more modern and easier to use than GitHub's and working with the same customers that we have since the beginning to do so.
would love to hear what you think we can do better to address your needs
(Graphite dev here)
Yeah – the key thing here is that there is work to be done on the server, so JJ likely either needs its own forge or a GitHub App that handles managing PRs for each JJ commit.
I'm a huge fan of the JJ paradigm – this is something I'd love for us to be able to do in the future once one or both of: - we have more bandwidth to go down this road - JJ is popular enough that its worthwhile for us to do
That said I'd also love to see if anyone in the community comes up with an elegant GH app for this!!
We've already soft launched the next step toward this to some existing Graphite users, so I'm fine sharing!
We're adding an agentic chat sidebar to the pull request that can help you gather context to understand a PR and make pre-merge changes without needing to leave the PR page. Open beta next week.
We're only going to spend more and more time looking at diffs as the amount of them increases, so the tools that we use here need to evolve as well. "AI code review" should be an interactive experience that directly builds on how code is reviewed today, not just a bot that comments on your PRs.
AI will certainly make human code review easier — the goal being to keep up with the velocity of changes to existing large systems.
"Code review" as defined as a human in the loop getting the final say on whether a change will be made to the system will be the absolute last thing to go. That process may look very different as both the inputs massively increase in scale and the methods get disrupted by AI.
lol. human code review is all we will do day-to-day in a year
(i'm the lead engineer on diamond)
a lot? what are the other ones?
I work on the Graphite CLI – curious what you don't like about it and what your flow with raw Git is – I assume you're mostly using `--update-refs`?
I feel like an LLM agent could grok and interact with something like this pretty well...
We (Graphite) love Jujutsu – comes up in conversation all the time here.
A prior version of the CLI is open source, the core data model (using git refs to store some extra data about what a branch's parent is) is still the same. https://github.com/withgraphite/graphite-cli
We've talked about supporting other clients, but don't currently have the bandwidth to build something like that – definitely something I am personally passionate about making sure happens at some point.
The funny thing is — this is actually different from how OSS (the initial model that Git was built for) worked. Patches are just applied as a single linear commit to the trunk branch.
Committing the history of individual work to the source of truth remote was definitely not the intent of merges.
You don't lose it long term if you're using GitHub PRs — GitHub keeps the "reflog" (quoted because I imagine their implementation may not actually use reflog) of the branch indefinitely, even after force pushes. Graphite (built to replicate the Phabricator workflow) enables viewing and diffing these versions. (disclaimer, I helped build this)
Phabricator and Gerrit both do a really good job of this. To me Git works fine as a pure "version control" system, but the process of collaborating on a branch before it gets merged into a shared branch seems to be beyond the scope of version control -- something that a higher layer tool is ideal for.
Plenty of folks are!
and then you send it to your friend on the weekend for a blind approval? :P
Net new feature development is often 20% or less of the job. With most guidelines like this, it's always possible to find exceptions -- but understanding why you're making the tradeoff in that situation is key.
With that said, using methods like stacking and feature flagging, I've been finding even new feature development to be possible while keeping my PRs to roughly 5 files changed or less.
I like this take. The onus is on these devs to learn how to use available tools effectively to split up their changes.
There's a clear parallel here to the idea of a "genius" who isn't able to communicate their ideas effectively. Can they really be considered that smart if no one understands them?
I think that this video should be considered mandatory viewing if you're a developer using Git — the whole lecture starts from the basic data structures involved and builds from there, as opposed to the way that it seems many people approach Git: "What command do I run?"