fosterfriends

14 ms·

151.
by fosterfriends 3y ago
++, having played with all three, agreed
152.
by fosterfriends 3y ago
Im a huge fan of this tool - I really like using it. I've started preferring it over google, and only googling after Phind fails me. Great work y'all! Keep it up :)
153.
by fosterfriends 3y ago
Out of curiosity, how do they sync through Twitter's now-very-closed API?
154.
by fosterfriends 3y ago
As someone new to the Twitter sphere - could some help me understand Nitter?
155.
There are no true monorepo companies(graphite.dev)
12 points by fosterfriends 3y ago|6 comments
156.
by fosterfriends 3y ago
There is no such thing as a true monorepo company.
157.
by fosterfriends 3y ago
I like that this comparison shows pg_vector in a positive light. After playing around with a few of the options at my company (graphite.dev), I’m a big fan of the simplicity of Postgres for everything. I understand there’s scaling costs, bu
158.
by fosterfriends 3y ago
I used to laugh a the "let's enhance" (and still do), but watching generative image models get better, I wonder if fiction will become a reality, abet with lots of hallucinations. At least the enhanced reflections of perpetra
159.
by fosterfriends 3y ago
Nice find!
160.
by fosterfriends 3y ago
It saddens me so much lol. Im determined to find evidence for writing good descriptions, but hey, all the more interesting if I cant
161.
by fosterfriends 3y ago
++ to stacking - google has lots of folk's writing on this, ie: https://benjamincongdon.me/blog/2022/07/17/In-Praise-of-Stac... The general idea is that you have a chance to parallelize waiting for
162.
by fosterfriends 3y ago
I like adopting a merge queue as a forcing function to deal with flaky tests.
163.
by fosterfriends 3y ago
It's like a rebase queue, but with more ref-log, and less tree inversion. Pull queues counter-intuitively lean on force-push-with-lease sub-commands, whereas monorepo merge queues have remote build caches for... sorry I blacked out.
164.
by fosterfriends 5y ago
Thank you for the kind words!
165.
by fosterfriends 5y ago
This is exactly the problem that graphite-cli solves ( https://github.com/screenplaydev/graphite-cli ) It keeps track of branchs and their parents by storing a tiny bit of metadata in the native git refs. It uses that in
166.
by fosterfriends 5y ago
We tried manually rebasing too, before building Graphite. The challenge you face with manual rebasing is two parts: 1) If you update the bottom branch, you need to manually rebase each branch above it. That becomes brutal if your stack is &
167.
by fosterfriends 5y ago
That pain was what inspired us to create Graphite as well :) Thank you
168.
by fosterfriends 5y ago
Great question! It does lots of things. The CLI ( https://github.com/screenplaydev/graphite-cli ) lets you: - Recursively rebase changes to keep your branches correctly stacked - Allow you to shift half of a stack onto a
169.
by fosterfriends 5y ago
Some of the other blog posts and docs have some good deeper info: - CLI docs: https://docs.graphite.dev/guides/graphite-cli - Dashboard docs: https://docs.graphite.dev/guides/graphite-dashboard -
170.
by fosterfriends 5y ago
Even if you're not a fan of stacking your changes, I think the web dashboard has a lot of fan favorites from the now deprecated Phabricator, such as seeing the PR comment timeline side-by-side the code, macros, showing lines that were
171.
by fosterfriends 5y ago
The website lets you merge in a stack of approved PRs together, (similar to Facebook's land all). Helps when merging in tons of small changes together. As far as the name, at least the CLI command is clean/similar to git - `gt` :)
172.
by fosterfriends 5y ago
The docs for the CLI and dashboard go into some more depth - might be what you're looking for? - https://docs.graphite.dev/guides/graphite-cli - https://docs.graphite.dev/guides/graphite-dashb
173.
by fosterfriends 5y ago
Thank you for the feedback :)
174.
by fosterfriends 5y ago
I came from Airbnb (vanilla github) and some friends converted me to a stacked workflow. I think the challenge with vanilla git is that rebasing and re-pushing becomes a brutal process if you stack 3+ changes. (At facebook people regularly
175.
by fosterfriends 5y ago
Google had a good paper on the benefits of smaller changes: https://sback.it/publications/icse2018seip.pdf > A correlation between change size and review quality is acknowledged by Google and developers are strongly
176.
by fosterfriends 5y ago
The part of Graphite that helps manage stacked changes locally is open source - you can see how it handles the recursive rebases here: https://github.com/screenplaydev/graphite-cli/blob/main/src/...
177.
by fosterfriends 5y ago
(Graphite engineer) We had the same problem. Coded in a feature that prevents you from casually merging branches that are not bottom of the stack :)