jacobegold

8 ms·

1.
by jacobegold 7mo ago
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 u
2.
by jacobegold 8mo ago
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
3.
by jacobegold 8mo ago
Yep. We see this future and are working on exactly what you're talking about (Graphite)
4.
by jacobegold 9mo ago
As a Graphite employee, would love this tbh - we love Blacksmith!
5.
by jacobegold 9mo ago
Maintained, improved, and integrated. With more resources than ever. We're building whole platform. That's a lot more than just AI.
6.
by jacobegold 9mo ago
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`
7.
by jacobegold 9mo ago
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 t
8.
by jacobegold 9mo ago
stacked prs will only get better from here :) we have an incredible amount of resources to keep improving that part of our product.
9.
by jacobegold 1y ago
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?
10.
by jacobegold 1y ago
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
11.
by jacobegold 1y ago
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?
12.
by jacobegold 1y ago
hell yeah
13.
by jacobegold 1y ago
(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 peo
14.
by jacobegold 1y ago
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,
15.
by jacobegold 1y ago
(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 – thi
16.
by jacobegold 1y ago
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
17.
by jacobegold 1y ago
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
18.
by jacobegold 1y ago
lol. human code review is all we will do day-to-day in a year (i'm the lead engineer on diamond)
19.
by jacobegold 1y ago
a lot? what are the other ones?
20.
by jacobegold 1y ago
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`?
21.
by jacobegold 2y ago
I feel like an LLM agent could grok and interact with something like this pretty well...
22.
by jacobegold 2y ago
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
23.
by jacobegold 3y ago
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
24.
by jacobegold 3y ago
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
25.
by jacobegold 3y ago
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 scop
26.
by jacobegold 3y ago
Plenty of folks are!
27.
by jacobegold 3y ago
and then you send it to your friend on the weekend for a blind approval? :P
28.
by jacobegold 3y ago
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, usi
29.
by jacobegold 3y ago
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 eff
30.
Fine, I'll talk about front end versus back end [video](youtube.com)
1 points by jacobegold 3y ago|0 comments

More ›