Imagine you have 3 branches: local-dev-tuneup, bugfix-a, feature-b
Remember in JJ you're always "in a commit", so the equivalent of the git working tree (i.e. unstaged changes in git) is just a new commit, often with no description set yet. (Because in JJ a commit also doesn't need a description/commit message immediately).
So in a mega-merge you can have a working tree that pulls from local-dev-tuneup, bugfix-a, and feature-b, and you can then squash or split changes out of it onto any of those source branches. Like you can avoid serializing those branches before you're ready to.
I've definitely faced the scenario in Git where I have a unmerged changes that I want to use while continuing work on a feature branch. I end up creating a PR for the branch of the first smaller features (e.g. local-dev-tuneup->master), then a second PR pointing at the first (feature-a -> local-dev-tuneup). It works but it's all a bit cumbersome, even more so if feature-a ends up needing to land before local-dev-tuneup. JJ has better tools for handling this.
Or potentially a team member has critical changes with a PR open and you want to start building on top of their changes now. Manageable in Git but you're locked in on a branch of their branch. Now add a second set of critical changes. Can be done in git but you'll be jumping through hoops to make it happen.
Of course you might say that all indicates a workflow/process problem, but my experience is this situations are common enough but not frequent.
(I haven't actually used megamerges myself yet but the article has me ready to try them out!)
Proceeds to write the hypiest comment possible. No substantial claims of why the model is not hype, just how dangerous it would be if the weights leaked and how cheap it would be for anyone to just start using it for EVIL if it ever did.
I don't think you've nailed it either. He SHOULD be saying "54 days ago, I powered on my computer and opened a terminal. From my editor I reviewed my code files and realized I had quite a mess on my hands. Realizing it was the year A.D. 2026, I decided to fire up a modern tool. I typed "claude" into my terminal. As it launched I told it I wanted helping taking my running programs and moving them from the virtual private servers I was running in Linode (inc) and Digital Ocean (co) to Hetzner (LLC). As Claude used it's tool use abilities it read the files and made suggestions on how to do the migrations, it indicated that it could go ahead and copy the files and run the needed commands but I would need to give it permission first. I granted it permission. Once it said the services were running, I instructed it to test that they were accessible and reliable while I reviewed the glowing new code it had written. In summary, with the help of Claude Code I was able to redeploy 37 services in Hetzner."
I think the parent has a point. For how many other accomplishments is the tool framed as the responsible party? We don't say "cranes built the skyscraper", people did. Why do we shift accountability when it comes to AI?
On Monday a crane company announces it’s pivoting to AI, followed by a quick 600% boost to its stock price. I wouldn’t even be surprised at this point.
That basically means nothing. The article is very light on details.
Go into Claude right now. What does it have? Internet access after you prompt it.
Ok now pull out your phone, a credit card, a security camera. You can say "Claude these are yours, run a business", but nothing's going to happen until you build an actual harness.
Like the idea presented by the article is interesting, but it's basically just a fluff piece. The actual interesting article would have way more detail.
You’re not wrong, but the commenter I responded to clearly hadn’t bothered to read it at all since they were asking questions that are answered in the piece. And when that’s the case it’s hard to believe they would actually be interested in details even if they were available.
If you start a new job and on your first day they go "Yeah the last guy said we don't need a database, so he rolled his own." are you gonna be excited, or sweating?
Exception being perhaps "The last team chose to build their own data layer, and here's the decision log and architecture docs proving why it was needed."
If your language supports it, what is the overhead of working with SQLite?
What's special about SQLite is that it already solves most of the things you need for data persistence without adding the same kind of overhead or trade offs as Postgres or other persistence layers, and that it saves you from solving those problems yourself in your json text files...
Like by all means don't use SQLite in every project. I have projects where I just use files on the disk too. But it's kinda inane to pretend it's some kind of burdensome tool that adds so much overhead it's not worth it.
I use a local garagefs on my NAS for small/new side projects, and it’s on my Tailscale for easy access
- Lets me deploy stateless containers easily
- Let’s me leverage the NAS for local redundancy and a more centralized place to do backups
- When a project grows it’s easy to promote it to use a hosted S3
- Local S3 becomes a target for Litestream and Restic
- Developing against the local fs and then handling file storage is a huge friction, unless I’m using something like Rails that already has a good abstraction
Remember in JJ you're always "in a commit", so the equivalent of the git working tree (i.e. unstaged changes in git) is just a new commit, often with no description set yet. (Because in JJ a commit also doesn't need a description/commit message immediately).
So in a mega-merge you can have a working tree that pulls from local-dev-tuneup, bugfix-a, and feature-b, and you can then squash or split changes out of it onto any of those source branches. Like you can avoid serializing those branches before you're ready to.
I've definitely faced the scenario in Git where I have a unmerged changes that I want to use while continuing work on a feature branch. I end up creating a PR for the branch of the first smaller features (e.g. local-dev-tuneup->master), then a second PR pointing at the first (feature-a -> local-dev-tuneup). It works but it's all a bit cumbersome, even more so if feature-a ends up needing to land before local-dev-tuneup. JJ has better tools for handling this.
Or potentially a team member has critical changes with a PR open and you want to start building on top of their changes now. Manageable in Git but you're locked in on a branch of their branch. Now add a second set of critical changes. Can be done in git but you'll be jumping through hoops to make it happen.
Of course you might say that all indicates a workflow/process problem, but my experience is this situations are common enough but not frequent.
(I haven't actually used megamerges myself yet but the article has me ready to try them out!)