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`
Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.
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!
The biggest challenge is that an acquisition like this makes relying on the acquired product a giant risk for us, so our general policy is to stop relying on something once it gets acquired and try to migrate to something else, because it's just way too disruptive to find out a year later it's getting sunsetted and then have a shorter timeline to migrate off.
It's happened so many times that it's just part of how we do business, unfortunately.
Obviously what you need to say but the reality is that you’re not in control anymore. That’s what an acquisition is.
If Cursor wants to re-allocate resources or merge Graphite into to editor or stagnate development and use it as a marketing/lead gen channel, it will for the business.
Anything said at time of acquisition isn’t trustworthy. Not because people are lying at the time (I don’t think you are!) but because these deals give up leverage and control explicitly. If they only wanted tighter integration, they could fund that via equity investment or staffing engineers (+/- paying Graphite to do the same.) Companies acquire for a reason and it isn’t to let the team + product stay independent
The worst offender is a slack notification[0] deep link into a PR I need to review.
It loads in stages, and the time from click to first diff is often so frustratingly long that I end up copying the PR ID and going to GitHub instead.
Sometimes I give up while Graphite is still loading and use the shortcut C-G to go to GitHub.
The second issue might be the landing page. I love what it shows compared to GitHub, but it's often slow to display loading blocks for things that haven’t even changed. Reloads are usually fast after that — until sometime later, maybe a day, when it slows down again.
I don't know why it feels worse than Linear, even though there are clearly many similarities in how it's supposed to load.
The guest instance isn’t so much about loading speed, but usage speed.
When I submit a stack of PRs, I get a nice carousel to fill in PR titles/descriptions and choose where to publish each PR.
What’s missing for me there is access to files and diffs, so I can re-review before publishing. I often end up closing it and going back to the PR list instead.
[0] Thank God for those! You've made them much more useful than GitHub's. Also, the landing page is far more helpful in terms of what’s displayed.
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?
The fundamental problem is that git doesn't track branches in any sane way. Maybe it would be better to fix that? Fossil remembers what branch a commit was committed on, so the task branch itself is a change ID. That might be tricky to solve while also allowing git commands to mess with history of course. Fossil doesn't have that problem.
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
to be direct, there's really nothing for you to do — it's a branding issue. if i were to link graphite to any of the devs i know that are actually interested in improving their development workflow, they would immediately close out after one look at the landing page. they have zero interest in AI and certainly won't pay for it to be shoved down their throats. graphite is now perceived as an AI company first, not a developer company.
you state that users don't 'have to use ANY of our AI features' — does that mean you have an opt-out toggle that fully hides any mention of it (e.g. in your 'AI-powered PR page')? if so, how long will that stick around? how long will your core products remain unsullied once your investors start to pressure you to push AI more? these sort of concerns around long term direction keep myself and others from adopting graphite.
(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!
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!!
As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job.
Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.
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!
