Been using graphite nonstop since recording this and I’m even more sold. It feels like Tailwind when it clicks. Seriously y’all, I know it seems weird and scary at first but it is so much more pleasant
The suggestion of spending more money, and more importantly the ramp-up time of all team members, is basically a nonstarter for most teams where the current Git workflows work well and are well-understood. Still interesting to see new ideas in version control.
(disclaimer: I'm an engineer at Graphite) - With the bidirectional GH sync and essentially fully featured product at the free tier, we've built this to be very easy to try out individually without needing to get your whole team bought in and invest in education up front. Our longer term hope is that this workflow gets more and more common, so that this barrier to entry eventually dissolves away!
Yo this is already my GitHub flow. Stacking PRs, rebasing, force push for clean commit log. The one thing I hate is approving PRs one by one and having to make sure the order of my stacked PRs are approved in the right order. Also having to update a previous branch in the stack and then rebasing all the stack above it individually Seems like this fixes this nuisance Edit: After using it this morning I can fully conclude that this is the shit. I had a backlog of 9 branches that I had to stack into a PR. All I had to do was run `gt track` and choose the parent for each branch I made before using graphite. Then I ran `gt-ss` and it stacked all my branches into a stack of PRs. Amazing. It turned out I had forgot to push a branch to remote and Graphite found it and recommended for the child to to track it. Sick! Cheers to the time save in the future
this indeed feels like a game-changer if you do a trunk-based/small PRs workflow. wow. If I start a company, I would only use this to force good behavior into people. It's just so much harder with traditional git.
this netizen language is soooo difficult. shit && sick. how am i supposed to read it?? "sick" is somewhat old & ohkayish but now u guys are using even shit to mean good? u guys must be shitsick lol. get some meds, cure ur sickness, have a shit-free belly - u will feel good. trust me.
At least 50% yes. They did the hard git stuff so we don’t have to. The better ergonomics around reviews and notifications are a massive win though, I was using another product for that before and it was nowhere near as good 😅
@@t3dotggit's honestly a symptom of git being harder to use for new people. Atleast when it comes to my classmates I had to do a lot of convincing to make them learn git properly
@@flarebear5346This. A lot of people just want a GUI and for the thing to do a thing. I'm still learning Git in general, but my classmates make me more discouraged to dive deeper since they don't even know how to init a repo.
@@flarebear5346 (disclaimer, Graphite engineer here) - Totally! My first job was at a company where tooling like this was the default, so I honestly never really learned Git well until I started mapping these concepts on top of it to build this tool. At that job, the playing field felt much more level for junior folks because there wasn't a massive amount to learn before starting to be productive. Just make a small set of atomic changes, quickly push them up and get them reviewed, and make more changes on top if you need to :)
@@flarebear5346 Still in that phase myself. It's like my peers/classmates don't believe me when I say they *need* to learn git. It's not optional for most positions. Dudes are literally passing around Zip files to each other... Atrocious
I have a hard time using GUI git tools and automated/abstracted commands for git operations and stick to using plain git cli. It took a while getting used to, and I'm not a git guru by far, I just feel more comfortable that way, rebasing, merging, cherry-picking, bisecting, hell, even patch adding, all on the git cli
I mean.. Sure. But the workflows you are showcasing seems like a living hell to begin with. We should probably fix our processes so that we don't need to do stacked PR's in the first place.
I always felt like Git was just a low-level tool, prone to mistakes because of human factor. What we really lacked was high-level workflow automation thingy like this one you showed to us, which basically handles things we don't want to care about.
The problem with simplicity is when you have some non-trivial case and simplicity just falls apart. It's not a big deal in case of Graphite, because you can always fallback to using Git.
Theo likes to use new advanced tools and likes to challenge the established patterns to get a speed boost to lead his team ahead of competition! (tRPC, tailwind, Next, Clerk, Upstash, Axiom) are all parts that he uses NOW (2023-2024), and Graphite is a new addition to simplify his github workflow!
This, only I'm not sold on the "better looking" part. :) Gerrit was a bit confusing at first, but once you get used to it... yeah, it may be a bit barebones, but it doesn't waste screen real estate with lots and lots of frames and boxes. It's... tidy. Neat.
It seems to be a very handy solution. I'm the person who is rebasing, force-pushing and approving PRs, but my company is quite small, so handling 2-3 peoples PRs that way is not that painful. I would try the Graphite's approach, but there some issues: * No Windows support (there is wsl and they work on native support, but right now I'm out of luck) * There is VS code extension, but no support for Intellij yet So I'll try it on Monday on my Linux machine I'm concerned how well a mix of Graphite and "normal" PRs on the same repo going to work together. Probably the only way to know is to give it a try.
(Graphite engineer here) Give it a try and let us know how it goes! We're working on better support for more surfaces like Windows and IntelliJ, I'd recommend joining our Slack community to stay up to date with that progress :) And there is actually a way to get the webview from the VSCode extension running in your browser via a CLI command that hosts the same server. With respect to your second question - lots of folks have successfully adopted Graphite individually within larger teams - we've invested a lot of time into ensuring the bidirectional sync works well from all angles.
My company doesn't know the meaning of the term pull request. We all push to the same server and there's no review process, which means force push is 100% outlawed. We always rebase local, unpushed changes, we never rebase anything that has been pushed already. Works pretty well for us
That's a you problem. I like being aware of new tech, but I'm not interested in adopting everything. Like I get the value of this tool, but for my preferences I don't think it's worth the cost of additional abstraction. Make your own decisions and recognize that you can have the fanciest stack but it's only worth as much as you build.
Stop being susceptible to trends and just get good at the fundamentals. You're like a consumer drooling over Marvel merchandise. Or a moth to a lamp. Whatever you prefer. Most new things just reinvent the wheel without adding much benefit, often introducing problems that time tested solutions didn't face in the first place. We already see start-ups founded no more than 10 years ago struggle with technical debt because they chose a hype driven tech stack. Half of their choices are now deprecated whereas some 20-30 year old technologies still prevail. Graphite makes a Microsoft owned project, GitHub, a greater dependency of your workflow. It might not integrate well with different teams' workflow. It adds no extra features. It delays the day you'll eventually have to learn git (which is needed if you switch to a workplace that uses GitLab or Gitea). It seems that Graphite has forced the git usage with the worst possible GitHub experience to force reviewers to also use their product. If you want a clean commit history while having lazy commit habits just squash before merging.
The review UI looks like a significant improvement over github. I'm not so sure about the local workflow; I love my git worktrees and existing shell shortcuts. I do already conduct my work in terms of changes; the initial commit for a change usually comes before its branch. I'm really curious how it handles the force pushes when you have someone else depending on your changes in their own changes and the new version you push causes a conflict with theirs. This has been the big pain point with force pushes in my experience and I don't see a clear way that Graphite could resolve that, being built on top of git still.
(eng @ Graphite) Because we track each branch as not just a pointer to a commit, but as a range of commits that can be moved around at will, we'll automatically pull down the new version of your coworkers branch and keep yours stacked on top of it - so we "restack" your changes on your coworker's!
@@Jacob-Gold it sounds like the equivalent of a rebase replaying the local commits on top of the updated remote branch, which is exactly what's caused me a lot of headaches in the past. Did I understand correctly?
@@3ventic Oops, looks like my reply never posted! We do something likely very close to what you used to do, with one key difference. The CLI tracks the _beginning_ of each branch as well as its parent, so when we "restack", we only replay those commits actually included in the stacked branch. To be concrete, let's say my coworker has a branch A consisting of commits 1-2 and I have a stacked branch B where I added commits 3-4. If my coworker rebases that branch, of course, new comits 1'-2' will be created. Now I update my copy of A to match. Running just a `git rebase A B` will attempt to replay all commits from the merge-base of A and B onto A, which results in replaying 1-2-3-4 on top of 1'-2', so you end up being asked to resolve conflicts between two commits that did the exact same thing. Instead, what we want to do is `git rebase --onto A B`, which will only replay 3-4 on top of A. Source: git-scm.com/docs/git-rebase The Graphite CLI keeps track of that in its metadata to ensure that you only ever get sent to conflict resolution when there are truly conflicting changes to resolve. If the explanation here wasn't super clear, we have a blog post coming out soon that explains this in more detail!
Zack Freedman said it best on his diamond nozzle 3d printer video --- "This video is sponsored. I love this so much I would have made this video anyway. I'm not shilling. I'm scamming. There's a difference."
[I work at Graphite] - When a restack hits a conflict, it puts you in the same that a git rebase would - so let's say I modify a branch which has another one stacked on it that changes the same file. The modify command under the hood would first amend the commit (or create a new one), then start the rebase. If your modification conflicts with the stacked branch, the CLI will then pause the rebase and have you resolve that conflict just like Git!
It's interesting but it doesn't seem to drastically change anything, for most companies they're not going to pay for this and like react and other frameworks businesses will just go with what works and what is popular to make sure they can hire engineers. This feels like you need to know git already and then use this which again doesn't really make it appealing since you can do pretty much all this in git.
I thought about this extensively in the past and I think we should go much further. Our IDEs should track the changes we make by saving AST diffs that retrace our steps, rather than plaintext diffs from commits. Commit is the wrong abstraction for changes. These AST diffs could then be rolled up to a single "chunk of change" (or commit). That way every "chunk of changes" could live independently of one another, almost like a Photoshop layer that you could toggle visibility for on or off. Git needs to be fundamentally rethought, and this isn't going far enough. This Graphite tool isn't the 10x improvement that would make me want to re-learn how I use git today, and I don't think it'll be sufficient for large orgs, given the learning curve that's already involved.
@@tapwater424 I mean you'd get a better experience if you were to use a language with an AST representation, or some other more advanced representation of changes. Obviously for regular text files you'd still fallback to plain old diff, but even then you could still make rebasing less of a thing by having the editor track incremental changes much more granularly than by commits. Let's say you move a paragraph from 3rd line, to 5th line, and a different committer simultaneously adds a few words to that paragraph on the 3rd line. When you rebase against each other, right now you need to resolve that conflict manually. If the VCS were to track what *actions* you performed (i.e. "moving the paragraph down 2 lines", "inserting words inside the paragraph"), it could resolve the conflict automatically, by re-applying the same changes in the new position.
@@itsbazyli Sounds like it would be heavily integrated to the IDE then. Git's strength is that it works with any editor and it works nicely with almost any file. But more importantly: git is very performant compared to other version control systems. Internally git does not use diffs*, that's purely a human readable representation. Git stores a full blob for each version of a file. If you modify a 1 kb file six times it creates approx 6 kb of blobs. If git had to do expensive calculations for each operation it would be unusable with large projects. Large C++ projects are already impossible to compile on machines with 8 GB ram because the AST is too large. Imagine trying to store the one million commits of the Linux kernel as an AST in your computer's memory. *exceptions are files larger than core.bigFileThreshold (512mb by default) and some other weird heuristics
@@tapwater424 Well I see this IDE/editor integration as an optional addition. If you have it, you get better experience, but if not, you fallback to the regular diffing. As far as your performance argument, I completely disagree. One of my gripes with git is that it is incredibly slow when doing anything more advanced. Regular rebases sometimes take tens of seconds of computation, even on top-of-the-line hardware. The reason git is so slow is because it reapplies the same changes over and over, and does it in the filesystem. The layering system would be much faster, because if wouldn't need to recompute the same changes every time (they could easily be cached), and it wouldn't operate on the FS until all the operations were fully applied in memory.
This has been my git flow for a while, even without additional tooling. I get looked at like I'm insane... Maybe now I can convince some folks to get on board, since there's finally a cargo cult to join 😂
GitLab already does the "diff between force-pushed versions" btw, and the rest of it is just a handful of aliases/functions... not convinced this is *that* useful
One feature that I think Graphite is missing that would make it an instant sell for me. Is the ability to create Stack Changes on Multiple Repos at the same time.
To be honest I trust you (at least for now) so idc if you're getting paid or not, but this looks awfully compicated and i'm not so sure if it actually solves any problem 🤔
If we force push, then the commit that was replaced wouldn't be orphan now? that means that if I do a git garbage collection and prune, that commit would be lost forever? Or am I misunderstanding?
I don’t care a lot about the github notification, but having an easy way to track dependencies across PRs would be great since I’m often the bottleneck (team waiting for my review) and teammates have to remember to update everything in the correct order after approval. Problem is, convincing my team to use this :,)
You can do that in GH, just set your dependent PR's base branch as the other PR's branch. Once the other PR is merged, GH will automatically switch the base branch of your dependent PR to the branch the parent PR was merged to. Works great for stacking multiple PRs and keeping track of dependencies.
@@itsbazyli I didn’t know that, thank a lot! I’ll look into it to see if it covers my use case. Does it also prevents to merge the second branch if the branch it’s dependent on isn’t merged yet?
I do stacked PRs all the time. I wish GitHub had better support for it. At least, they seem to have resolved the ghost merge conflicts that you get when the base branch auto-switches to main.
(Graphite eng here) - The best I can tell, they are still around - they just only show up when two consecutive stacked PRs change the same file, and you are using either Squash-and-merge or Rebase-and-merge. Our "Merge N..." button does a rebase in between each PR to get rid of the ghost conflict so that we can merge each PR without hitting the ghost conflict. We're doing some fun `git cherry` calculations on the backend to ensure we handle all the edge cases :)
@@Jacob-Gold Already have and it's great :) I'd love to use this at work but fear my company won't be open to onboarding more tooling with git access :(
Kind of my workflow for very large changes. Though a bitch to keep up to date. So it looks very interesting, but I'm worried about the amount of PR it generates. And the review combination between Github usage and Graphite usage would probably get messy. Will try using Graphite for reviewing though.
"Huge shoutout to Graphite for sponsoring this video and making a tool I can't imagine life without." C'mon, Theo. I know you have integrity and I want to trust you, but, geeze, it pains me to see my YT faves carrying on about something "sponsored." You weren't just hyped to talk about Graphite, you were paid to.
God that would be so helpful with big refactors! My nemesis of the month is trying to somehow split into reviewable PRs a changeset of +4000 -5000 where all things sequentially depend on each other. And before you say something like "that should have been decomposed in multiple tasks" - yeah sure I know, but I kinda want it to be done this year and not next one. So far merging the code takes longer than writing it. Ehh... I wonder how much effort it would be to convince the client that we need a tool like that.
It's a bit sad that their CLI doesn't work without integrating the github app which would need some convincing to do every time. I kinda get it's a team based pricing model, but as a contractor dev I would gladly buy right damn now myself even in limited functionality without the web UI part (even just for automatic "this pr depends on those other ones" comments). But as I understand the actual github api calls are made from their server.
Is this just for teams that are all usijg graphite? What happens if your using a open-source project, can you still use graphite with it and others can use regular github?
(Graphite engineer here) We don't yet support submitting cross-repo PRs, but as long as you have write perms to the repo, you can adopt Graphite as an individual due to the bi-directional sync.
For those who have worked at Google: this is basically just cl/ and hg on top of Git. But question: I have one big commit with bunch of files. Now I want to break into smaller stacked PRs. How?
I tried it out on my project. The first time I wanted to tried to merge a stack it broke on me and I had to merge 30+ PRs manually, syncing, submitting, rebasing, using all my CI quota. Very bad experience.
50% of that git has had for years and the other 50% Gitlab has. The dashboard is really clever, though. I figure it to be rather opinionated to say you didn't use certain git commands just because you're scared. Sounds not very convincing, but I kind of get it.
No thank you, i can see the appeal. But this increases the cost and increases the complexity(more things to learn, ui, cli to get used to, abstraction etc). most of it seems to be some git commands and some small kind of svn ideas, which is cool, not sure what to think about it.
Sigh... careful kids, there's no substitute to learning the hard stuff. Sure, you can hide and abstract away the hard low level internals, but like a wise man once said: "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection"! (or something to that affect) ...and that was when they didn't have to pay 30$ for yet another abstraction. I'm sorry. No... NOPE!
This looks a lot like the tooling Google has. It’s not quite at that level, but it’s close. Really great to see this stuff be a thing outside the Google tech island now!
(Graphite engineer here) We have engineers on the team from both Google and Facebook (which has similar tooling) who also really miss it! Seeing people so excited to be able to re-adopt the workflow they used to have at companies with stacked changes tooling is one of our most important motivations! We'd love your feedback as we keep iterating on a version of this that works for all sorts of teams :)
I think you are little bit overhyped about this one.. Can be little bit more visually apealing - maybe, but if you get use to what info is where in gh not that much of a differnce. Cool shorter commands - yes - you can also achieve that having aliases in git. I do not see that big benefit for an developer to be able to save 30seconds of going through all of that shit.. to grab another coffee quicker? What would have bigger impact for my dev experience - having better diff tool and git integration inside VsCode, similar to the one IntelliJ has.
Not shown here is the complexity of configuring your CI to work with all these PRs. Especially if you are in a monorepo and one (or more) long running CI jobs. There is a lot of work to make this barely useable, from the standpoint of trying to take a large code base and large team to switch to using this.
I think you just need to learn git cli, feature workflow and rebasing properly. Graphite will hide away all of that and when comes to edge cases that will likely happen, users without proper git knowledge will surely stumble since they are so used to these kinds of another layer on top of basic git.
I don't see much benefit of this for teams proficient in git. Usually, it's not git that slows devs down, it's the management software/code review workflow that takes longer than it should. Either because of the management mistakes or tools lacking on DX side.
As a primarily back-end dev with longer lived branches (days vs minutes) in relatively static code bases (weekly to monthly releases) this seems useless for me or I just don't see a use case that's better than default git branch/pr/merge with stashes.
This tool seems like a bloated git addon. I'd say half of these "oh-sh*t" features could be replicated with a free package, with no signups or credit cards required.
![[TH] 2024 PMGC League | Survival Stage วันที่ 1 | PUBG MOBILE Global Championship](http://i.ytimg.com/vi/FVFT-PFwU80/mqdefault.jpg)
Been using graphite nonstop since recording this and I’m even more sold. It feels like Tailwind when it clicks. Seriously y’all, I know it seems weird and scary at first but it is so much more pleasant
Congrats on reinventing Gerrit on top of GitHub 😊
youre always being "more sold" by products you talk about
The suggestion of spending more money, and more importantly the ramp-up time of all team members, is basically a nonstarter for most teams where the current Git workflows work well and are well-understood. Still interesting to see new ideas in version control.
nah we already switched to graphite at our company couldnt have said it better than Theo about graphite being the tailwind of css but for vc
(disclaimer: I'm an engineer at Graphite) - With the bidirectional GH sync and essentially fully featured product at the free tier, we've built this to be very easy to try out individually without needing to get your whole team bought in and invest in education up front. Our longer term hope is that this workflow gets more and more common, so that this barrier to entry eventually dissolves away!
Yeah but you literally can’t fuck this up.
Imagine if in tech companies didn’t improve or change just because it would take a bit of time or money…
@@perc-ai If TW was costing money everyone would use regular CSS just fine
Yo this is already my GitHub flow. Stacking PRs, rebasing, force push for clean commit log. The one thing I hate is approving PRs one by one and having to make sure the order of my stacked PRs are approved in the right order. Also having to update a previous branch in the stack and then rebasing all the stack above it individually
Seems like this fixes this nuisance
Edit: After using it this morning I can fully conclude that this is the shit. I had a backlog of 9 branches that I had to stack into a PR. All I had to do was run `gt track` and choose the parent for each branch I made before using graphite. Then I ran `gt-ss` and it stacked all my branches into a stack of PRs. Amazing. It turned out I had forgot to push a branch to remote and Graphite found it and recommended for the child to to track it. Sick!
Cheers to the time save in the future
this indeed feels like a game-changer if you do a trunk-based/small PRs workflow. wow.
If I start a company, I would only use this to force good behavior into people. It's just so much harder with traditional git.
this netizen language is soooo difficult. shit && sick. how am i supposed to read it??
"sick" is somewhat old & ohkayish but now u guys are using even shit to mean good?
u guys must be shitsick lol. get some meds, cure ur sickness, have a shit-free belly - u will feel good. trust me.
I use Google Drive
I use src_backup_april_1st.zip :)
Sounds like 80% of this is just a couple of git commands that improve the mechanics of merging changes into remotely rebased branches
At least 50% yes. They did the hard git stuff so we don’t have to. The better ergonomics around reviews and notifications are a massive win though, I was using another product for that before and it was nowhere near as good 😅
@@t3dotggit's honestly a symptom of git being harder to use for new people. Atleast when it comes to my classmates I had to do a lot of convincing to make them learn git properly
@@flarebear5346This. A lot of people just want a GUI and for the thing to do a thing. I'm still learning Git in general, but my classmates make me more discouraged to dive deeper since they don't even know how to init a repo.
@@flarebear5346 (disclaimer, Graphite engineer here) - Totally! My first job was at a company where tooling like this was the default, so I honestly never really learned Git well until I started mapping these concepts on top of it to build this tool. At that job, the playing field felt much more level for junior folks because there wasn't a massive amount to learn before starting to be productive. Just make a small set of atomic changes, quickly push them up and get them reviewed, and make more changes on top if you need to :)
@@flarebear5346 Still in that phase myself. It's like my peers/classmates don't believe me when I say they *need* to learn git. It's not optional for most positions. Dudes are literally passing around Zip files to each other... Atrocious
I have a hard time using GUI git tools and automated/abstracted commands for git operations and stick to using plain git cli. It took a while getting used to, and I'm not a git guru by far, I just feel more comfortable that way, rebasing, merging, cherry-picking, bisecting, hell, even patch adding, all on the git cli
I've only used Graphite for a couple of days but the stack diff workflow completely changed how I think about organising changes
I'm one dev shipping to 0 users, I'll add this to my tooling!
ehhhh not paying $30 a month for this LMAO
cool but 30 per dev per month is ....INSANE pricing
idk microsoft word revision history is pretty crazy
I use Excel for version management
@@TheBswanExcel's a database, right? /s
So basically graphite is automating rebase and force push. It's already my usual flow for 3 years now.
I mean.. Sure. But the workflows you are showcasing seems like a living hell to begin with. We should probably fix our processes so that we don't need to do stacked PR's in the first place.
definitely going to be checking this out.
No
this is definitely much more complicated than github flow.
tell us theo how much did you get paid for this?
Git flow is terrible anyway. Don't use git flow
I always felt like Git was just a low-level tool, prone to mistakes because of human factor. What we really lacked was high-level workflow automation thingy like this one you showed to us, which basically handles things we don't want to care about.
The problem with simplicity is when you have some non-trivial case and simplicity just falls apart. It's not a big deal in case of Graphite, because you can always fallback to using Git.
this reminds me a lot of the gerrit workflow
exactly what I said ^
Inspired by it!
My immediate thought as well.
Theo likes to use new advanced tools and likes to challenge the established patterns to get a speed boost to lead his team ahead of competition! (tRPC, tailwind, Next, Clerk, Upstash, Axiom) are all parts that he uses NOW (2023-2024), and Graphite is a new addition to simplify his github workflow!
That looks like a better looking Gerrit I've been using since 2017... stack diff looks very similar to Gerrit's "patch set" system
This, only I'm not sold on the "better looking" part. :) Gerrit was a bit confusing at first, but once you get used to it... yeah, it may be a bit barebones, but it doesn't waste screen real estate with lots and lots of frames and boxes. It's... tidy. Neat.
Maybe it looks better but unsure it's more functional. Gerrit 3.X doesn't look bad at all.
It seems to be a very handy solution. I'm the person who is rebasing, force-pushing and approving PRs, but my company is quite small, so handling 2-3 peoples PRs that way is not that painful.
I would try the Graphite's approach, but there some issues:
* No Windows support (there is wsl and they work on native support, but right now I'm out of luck)
* There is VS code extension, but no support for Intellij yet
So I'll try it on Monday on my Linux machine
I'm concerned how well a mix of Graphite and "normal" PRs on the same repo going to work together. Probably the only way to know is to give it a try.
(Graphite engineer here) Give it a try and let us know how it goes!
We're working on better support for more surfaces like Windows and IntelliJ, I'd recommend joining our Slack community to stay up to date with that progress :) And there is actually a way to get the webview from the VSCode extension running in your browser via a CLI command that hosts the same server.
With respect to your second question - lots of folks have successfully adopted Graphite individually within larger teams - we've invested a lot of time into ensuring the bidirectional sync works well from all angles.
My company doesn't know the meaning of the term pull request. We all push to the same server and there's no review process, which means force push is 100% outlawed. We always rebase local, unpushed changes, we never rebase anything that has been pushed already. Works pretty well for us
Theo make feel like you are in a race whenever a new technology release he switches
That's a you problem. I like being aware of new tech, but I'm not interested in adopting everything. Like I get the value of this tool, but for my preferences I don't think it's worth the cost of additional abstraction. Make your own decisions and recognize that you can have the fanciest stack but it's only worth as much as you build.
Stop being susceptible to trends and just get good at the fundamentals. You're like a consumer drooling over Marvel merchandise. Or a moth to a lamp. Whatever you prefer.
Most new things just reinvent the wheel without adding much benefit, often introducing problems that time tested solutions didn't face in the first place. We already see start-ups founded no more than 10 years ago struggle with technical debt because they chose a hype driven tech stack. Half of their choices are now deprecated whereas some 20-30 year old technologies still prevail.
Graphite makes a Microsoft owned project, GitHub, a greater dependency of your workflow. It might not integrate well with different teams' workflow. It adds no extra features. It delays the day you'll eventually have to learn git (which is needed if you switch to a workplace that uses GitLab or Gitea). It seems that Graphite has forced the git usage with the worst possible GitHub experience to force reviewers to also use their product. If you want a clean commit history while having lazy commit habits just squash before merging.
Next week news: "Graphite announces it has Joined Microsoft and will merge with Github"
Very cool tool. Thanks for sharing.
This tool is like a Stash-on-steroids synced and mergeable. A big UX improvement on git.
I heard this same thing when I saw the Linus Torvals conference talk on git.
3:36 everything is click-baity nowaways man, no worries; so basically we're just working git but with an abstraction
The review UI looks like a significant improvement over github. I'm not so sure about the local workflow; I love my git worktrees and existing shell shortcuts. I do already conduct my work in terms of changes; the initial commit for a change usually comes before its branch.
I'm really curious how it handles the force pushes when you have someone else depending on your changes in their own changes and the new version you push causes a conflict with theirs. This has been the big pain point with force pushes in my experience and I don't see a clear way that Graphite could resolve that, being built on top of git still.
(eng @ Graphite) Because we track each branch as not just a pointer to a commit, but as a range of commits that can be moved around at will, we'll automatically pull down the new version of your coworkers branch and keep yours stacked on top of it - so we "restack" your changes on your coworker's!
@@Jacob-Gold it sounds like the equivalent of a rebase replaying the local commits on top of the updated remote branch, which is exactly what's caused me a lot of headaches in the past. Did I understand correctly?
@@3ventic Oops, looks like my reply never posted! We do something likely very close to what you used to do, with one key difference. The CLI tracks the _beginning_ of each branch as well as its parent, so when we "restack", we only replay those commits actually included in the stacked branch.
To be concrete, let's say my coworker has a branch A consisting of commits 1-2 and I have a stacked branch B where I added commits 3-4. If my coworker rebases that branch, of course, new comits 1'-2' will be created. Now I update my copy of A to match. Running just a `git rebase A B` will attempt to replay all commits from the merge-base of A and B onto A, which results in replaying 1-2-3-4 on top of 1'-2', so you end up being asked to resolve conflicts between two commits that did the exact same thing. Instead, what we want to do is `git rebase --onto A B`, which will only replay 3-4 on top of A. Source: git-scm.com/docs/git-rebase
The Graphite CLI keeps track of that in its metadata to ensure that you only ever get sent to conflict resolution when there are truly conflicting changes to resolve. If the explanation here wasn't super clear, we have a blog post coming out soon that explains this in more detail!
@@Jacob-Gold That's sufficient detail, thanks! I'll ultimately have to give it a try to form a full opinion.
13:35 summary of graphite in a sentence (or two)
Zack Freedman said it best on his diamond nozzle 3d printer video --- "This video is sponsored. I love this so much I would have made this video anyway. I'm not shilling. I'm scamming. There's a difference."
What about handling conflicts?
[I work at Graphite] - When a restack hits a conflict, it puts you in the same that a git rebase would - so let's say I modify a branch which has another one stacked on it that changes the same file. The modify command under the hood would first amend the commit (or create a new one), then start the rebase. If your modification conflicts with the stacked branch, the CLI will then pause the rebase and have you resolve that conflict just like Git!
in summary,grahite grahite grahite
Very interesting, thanks for sharing.
It's interesting but it doesn't seem to drastically change anything, for most companies they're not going to pay for this and like react and other frameworks businesses will just go with what works and what is popular to make sure they can hire engineers.
This feels like you need to know git already and then use this which again doesn't really make it appealing since you can do pretty much all this in git.
I thought about this extensively in the past and I think we should go much further. Our IDEs should track the changes we make by saving AST diffs that retrace our steps, rather than plaintext diffs from commits. Commit is the wrong abstraction for changes. These AST diffs could then be rolled up to a single "chunk of change" (or commit). That way every "chunk of changes" could live independently of one another, almost like a Photoshop layer that you could toggle visibility for on or off. Git needs to be fundamentally rethought, and this isn't going far enough.
This Graphite tool isn't the 10x improvement that would make me want to re-learn how I use git today, and I don't think it'll be sufficient for large orgs, given the learning curve that's already involved.
Do you mean regular trees, or do you want git to only work for languages that can be represented in abstract syntax trees?
@@tapwater424 I mean you'd get a better experience if you were to use a language with an AST representation, or some other more advanced representation of changes. Obviously for regular text files you'd still fallback to plain old diff, but even then you could still make rebasing less of a thing by having the editor track incremental changes much more granularly than by commits.
Let's say you move a paragraph from 3rd line, to 5th line, and a different committer simultaneously adds a few words to that paragraph on the 3rd line. When you rebase against each other, right now you need to resolve that conflict manually. If the VCS were to track what *actions* you performed (i.e. "moving the paragraph down 2 lines", "inserting words inside the paragraph"), it could resolve the conflict automatically, by re-applying the same changes in the new position.
@@itsbazyli Sounds like it would be heavily integrated to the IDE then. Git's strength is that it works with any editor and it works nicely with almost any file.
But more importantly: git is very performant compared to other version control systems. Internally git does not use diffs*, that's purely a human readable representation. Git stores a full blob for each version of a file. If you modify a 1 kb file six times it creates approx 6 kb of blobs. If git had to do expensive calculations for each operation it would be unusable with large projects. Large C++ projects are already impossible to compile on machines with 8 GB ram because the AST is too large. Imagine trying to store the one million commits of the Linux kernel as an AST in your computer's memory.
*exceptions are files larger than core.bigFileThreshold (512mb by default) and some other weird heuristics
@@tapwater424 Well I see this IDE/editor integration as an optional addition. If you have it, you get better experience, but if not, you fallback to the regular diffing.
As far as your performance argument, I completely disagree. One of my gripes with git is that it is incredibly slow when doing anything more advanced. Regular rebases sometimes take tens of seconds of computation, even on top-of-the-line hardware. The reason git is so slow is because it reapplies the same changes over and over, and does it in the filesystem.
The layering system would be much faster, because if wouldn't need to recompute the same changes every time (they could easily be cached), and it wouldn't operate on the FS until all the operations were fully applied in memory.
@@itsbazyli are you a windows user by any chance?
This has been my git flow for a while, even without additional tooling. I get looked at like I'm insane... Maybe now I can convince some folks to get on board, since there's finally a cargo cult to join 😂
GitLab already does the "diff between force-pushed versions" btw, and the rest of it is just a handful of aliases/functions... not convinced this is *that* useful
Omg I absolutely love this. Will try to implement this in my work asap
One feature that I think Graphite is missing that would make it an instant sell for me. Is the ability to create Stack Changes on Multiple Repos at the same time.
I use git-stackless for a similar reason. Pairs really well with gerrit at work
To be honest I trust you (at least for now) so idc if you're getting paid or not, but this looks awfully compicated and i'm not so sure if it actually solves any problem 🤔
If we force push, then the commit that was replaced wouldn't be orphan now? that means that if I do a git garbage collection and prune, that commit would be lost forever? Or am I misunderstanding?
I don’t care a lot about the github notification, but having an easy way to track dependencies across PRs would be great since I’m often the bottleneck (team waiting for my review) and teammates have to remember to update everything in the correct order after approval. Problem is, convincing my team to use this :,)
You can do that in GH, just set your dependent PR's base branch as the other PR's branch. Once the other PR is merged, GH will automatically switch the base branch of your dependent PR to the branch the parent PR was merged to. Works great for stacking multiple PRs and keeping track of dependencies.
@@itsbazyli I didn’t know that, thank a lot! I’ll look into it to see if it covers my use case. Does it also prevents to merge the second branch if the branch it’s dependent on isn’t merged yet?
I couldn't exactly put my finger on it but this is what I have been looking for
I do stacked PRs all the time. I wish GitHub had better support for it. At least, they seem to have resolved the ghost merge conflicts that you get when the base branch auto-switches to main.
(Graphite eng here) - The best I can tell, they are still around - they just only show up when two consecutive stacked PRs change the same file, and you are using either Squash-and-merge or Rebase-and-merge. Our "Merge N..." button does a rebase in between each PR to get rid of the ghost conflict so that we can merge each PR without hitting the ghost conflict. We're doing some fun `git cherry` calculations on the backend to ensure we handle all the edge cases :)
Cool. Looks like a nicer Gerrit.
Too many abstraction layers away from Git. I just use git cli and once you learn that, you don't need all these abstractions that hide what's going on
too complicated.
nice lgtm
Hard to trust your opinion when you're sponsored
After your `gt modify`, do you have two commits on the PR, or it just one that replaces the older one?
I would've loved to see a conflict resolution at the base of a stack to see how graphite handles it as well
@t3dotgg said he might do another video about it, but you should try it out yourself! We tried to make it feel very natural coming from Git :)
@@Jacob-Gold Already have and it's great :)
I'd love to use this at work but fear my company won't be open to onboarding more tooling with git access :(
Kind of my workflow for very large changes. Though a bitch to keep up to date. So it looks very interesting, but I'm worried about the amount of PR it generates.
And the review combination between Github usage and Graphite usage would probably get messy. Will try using Graphite for reviewing though.
Pretty cool! The stack workflow seems really clean
"Huge shoutout to Graphite for sponsoring this video and making a tool I can't imagine life without." C'mon, Theo. I know you have integrity and I want to trust you, but, geeze, it pains me to see my YT faves carrying on about something "sponsored." You weren't just hyped to talk about Graphite, you were paid to.
God that would be so helpful with big refactors! My nemesis of the month is trying to somehow split into reviewable PRs a changeset of +4000 -5000 where all things sequentially depend on each other. And before you say something like "that should have been decomposed in multiple tasks" - yeah sure I know, but I kinda want it to be done this year and not next one. So far merging the code takes longer than writing it.
Ehh... I wonder how much effort it would be to convince the client that we need a tool like that.
It's a bit sad that their CLI doesn't work without integrating the github app which would need some convincing to do every time.
I kinda get it's a team based pricing model, but as a contractor dev I would gladly buy right damn now myself even in limited functionality without the web UI part (even just for automatic "this pr depends on those other ones" comments). But as I understand the actual github api calls are made from their server.
Is this just for teams that are all usijg graphite? What happens if your using a open-source project, can you still use graphite with it and others can use regular github?
(Graphite engineer here) We don't yet support submitting cross-repo PRs, but as long as you have write perms to the repo, you can adopt Graphite as an individual due to the bi-directional sync.
Is rebase concept came to have always an easy revert mechanism if anything goes wrong ?
For those who have worked at Google: this is basically just cl/ and hg on top of Git.
But question: I have one big commit with bunch of files. Now I want to break into smaller stacked PRs. How?
I don’t understand the value proposition vs Gitlab MR + MR guidelines for small MR
Does "gt sync" require syncing to main/master? Or is that branch configurable?
I feel like my workflow is similar like Graphite using only Git. I will have to test it to be sure😅
(Graphite engineer here) Let us know how it goes!
I tried it out on my project. The first time I wanted to tried to merge a stack it broke on me and I had to merge 30+ PRs manually, syncing, submitting, rebasing, using all my CI quota. Very bad experience.
Yeah, I was just thinking about this lol
are there similar open source implementations?
Gitlab integration would be so fucking cool.
So we using zip archive now?
Edit: 3:45 in .... we got jebaited
Theo is the tech industry's version of Karen.
50% of that git has had for years and the other 50% Gitlab has. The dashboard is really clever, though.
I figure it to be rather opinionated to say you didn't use certain git commands just because you're scared. Sounds not very convincing, but I kind of get it.
No thank you, i can see the appeal. But this increases the cost and increases the complexity(more things to learn, ui, cli to get used to, abstraction etc).
most of it seems to be some git commands and some small kind of svn ideas, which is cool, not sure what to think about it.
competition will be great for github
Sigh... careful kids, there's no substitute to learning the hard stuff. Sure, you can hide and abstract away the hard low level internals, but like a wise man once said:
"You can solve every problem with another level of indirection, except for the problem of too many levels of indirection"! (or something to that affect)
...and that was when they didn't have to pay 30$ for yet another abstraction. I'm sorry. No... NOPE!
Looks like gerrit, but with nicer UI.
Pretty impressive. Does anyone have experience with magit?
Do you use it at work with all your colleagues?
I gave up twice on learning git, until it finally clicked on the third attempt.
I was using a tool called stgit which is similar to this back in 2015
This looks a lot like the tooling Google has. It’s not quite at that level, but it’s close. Really great to see this stuff be a thing outside the Google tech island now!
(Graphite engineer here) We have engineers on the team from both Google and Facebook (which has similar tooling) who also really miss it! Seeing people so excited to be able to re-adopt the workflow they used to have at companies with stacked changes tooling is one of our most important motivations! We'd love your feedback as we keep iterating on a version of this that works for all sorts of teams :)
mmm i don't feel the difference to using git, specially when you use all vscode commands for git
I think you are little bit overhyped about this one.. Can be little bit more visually apealing - maybe, but if you get use to what info is where in gh not that much of a differnce. Cool shorter commands - yes - you can also achieve that having aliases in git. I do not see that big benefit for an developer to be able to save 30seconds of going through all of that shit.. to grab another coffee quicker?
What would have bigger impact for my dev experience - having better diff tool and git integration inside VsCode, similar to the one IntelliJ has.
Wow! I love the dashboard and I agree notifications sucks big time in GitHub. Thanks for the recommendation man!
Not shown here is the complexity of configuring your CI to work with all these PRs. Especially if you are in a monorepo and one (or more) long running CI jobs. There is a lot of work to make this barely useable, from the standpoint of trying to take a large code base and large team to switch to using this.
It's built on top of GitHub or it's built on top of Git?
Both!
GitHub is built on of Git, so both.
how fast is too fast
They should have called them layers...like photoshop.
Ineresting but not compelling enough for me
0:04 that not centered icon triggers me
VS Code theme?)
wow 😳
I think you just need to learn git cli, feature workflow and rebasing properly. Graphite will hide away all of that and when comes to edge cases that will likely happen, users without proper git knowledge will surely stumble since they are so used to these kinds of another layer on top of basic git.
I don't see much benefit of this for teams proficient in git. Usually, it's not git that slows devs down, it's the management software/code review workflow that takes longer than it should. Either because of the management mistakes or tools lacking on DX side.
No thank you I do not want to learn another repository command lines.
Next topic: I stop using computer 😊
As a primarily back-end dev with longer lived branches (days vs minutes) in relatively static code bases (weekly to monthly releases) this seems useless for me or I just don't see a use case that's better than default git branch/pr/merge with stashes.
Looks like gerrit
So its just an abstraction of git for script kiddies. cool
Theo, seriously stop the shilling. This is git with very minor improvements. Do not dilude your excellent videos with nonsense such as this.
I didn't see so much difference 🤔
1. Says that GitHub is awesome.
2. Advertises another proprietary solution.
3. Deserves dislike.
This tool seems like a bloated git addon. I'd say half of these "oh-sh*t" features could be replicated with a free package, with no signups or credit cards required.
I didn't get what the stack is. Any way, it's great to see any new GUI that streamlines work over git.
This is not what I‘ve spent years honing my git skills for