gregmfoster

Thanks for writing this up! I really enjoyed the comparison. My team is considering moving some of our data to elastisearch out of postgres, and this analysis helps confirm some of our thoughts.

To me, the critical points here are:

> PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding.

> if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better

I love the mentality of "default to using Postgres for everything, and specialize when you need to." In this case, it looks like you'll need to evolve text search out of Postgres the moment your dataset gets into the millions, which roughly matches my experience.

I love the idea of more book-focused social networks! Curious what the motivation here is to make it federated, instead of focusing on high-velocity user-focused product development. My greatest gripes with existing book-social-media-networks aren't the federation, but rather the dated UX.

I'm curious how much people prefer TUIs over editor-plugin-GUIs these days. I'm getting more and more persuaded by the plugin model personally - perhaps partly by how easy it is to discover, install, update, uninstall, etc VSCode plugins

I imagine this would be brutally hard for guitar - so often, my fingers are "touching" the correct strings, but not pushing down hard enough to trigger the note. Piano might be more feasible because you can watch the motion of the keys themselves.

Question - what is your root goal? Are you convinced video processing is the best way to achieve this?

yeah, it's really interesting, I've seen this confusion before

Congrats on the launch! How are you thinking about building an open-source company vs a closed-source?

why

nah, not real, I was just being silly :)

I like adopting a merge queue as a forcing function to deal with flaky tests.

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.

FWIW, graphite.dev's MQ supports GitHub Enterprise Server

semi-hot-take, if a merge queue is light and fast, all repos could benefit from having it enabled by default

Seeing 421 on our AWS amplify splash page as well

This comment seems off topic?

I wonder if folks can trade in dev kits for the first version when it's released next year. That was the case for me with the Apple TV dev kit.

We're seeing this from graphite.dev's API calls to GitHub

Sounds like have some really thoughtful opinions regarding code review tools!

> "Being able to comment on character-level granularity is cool!" This is something that I really like too - I'd go so far as to say PR titles, file names, etc, nearly everything should be commentable.

Have you checked out graphite.dev? Its iterating rapidly and incorporating a lot of what Phabricator and Gerrit did well.

Proud to be working with friends to improve the world of dev tools. There's a massive community of engineers on Slack who have been beyond generous with feedback, bug reports, and motivating messages. Makes grinding hard on Graphite meaningful :)

graphite.dev (alternative frontend to github code review) still up, it appears to be just their frontend.

Love to see the manually updated status page not updating

Down for us (graphite.dev) as well, running on us-west-2

Im a fan of keeping my git branches clean locally (only having a couple active branches) and aggressively deleting merged/abandoned ones, though I know that this can be contentious

Thank you for the kind words!

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 information to perform recursive rebases: https://github.com/screenplaydev/graphite-cli/blob/main/src/...

It ends up working seamlessly - you just modify some branch, and then run `gt stack fix` to recursively rebase everything. (and then `gt stack submit` to sync everything to github :)

docs here: https://docs.graphite.dev/guides/graphite-cli

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 >3 branches.

2) You cant perform a simple rebase-onto, because you'll copy all commits between the higher branch and trunk. You'd have to perform a three-way rebase, specifying the range of commits you'd like to copy onto the destination. This becomes infeasible by hand.

Graphite-cli gets around this by tracking branch metadata and storing it in native git refs (https://graphite.dev/blog/post/y6ysWaplagKc8YEFzYfr). When you rebase a stack, it recursively performs the three-way merge to fix things up smoothly.

On top of this, git provides no good mechanisms for submitting the stack. Graphite cli can submit/sync your whole stack as individual PRs, and can prune merged branches from the bottom of local stacks. Ends up coming together as a really powerful workflow :)

The cli is open source here: https://github.com/screenplaydev/graphite-cli, with docs here https://docs.graphite.dev/guides/graphite-cli. There's also an active Slack community which helps provide input on new features and adjustments.

Please let me know if you have any other questions!

Thank you! All thanks to Xiulung Choy's hard work

That pain was what inspired us to create Graphite as well :) Thank you

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 different branch

- Open up PRs/push changes for all the branches in a stack

- Offer to delete merged branches from local, rebases the remaining branches, and adjust github pr merge bases.

The web dashboard lets you:

- See an inbox of PRs spanning any number of repos, based on which ones need action

- Navigate between PRs in a stack

- Modify Prs, review, all of which is synced to Github

- Shortcuts, client side caching for fast loading, Phabricator style interface, macros, landing a stack of PRs together, and much more :)

Give the tool a try, we'd love to hear your feedback in the community Slack! https://join.slack.com/t/graphite-community/shared_invite/zt...