alt Hacker News> You don't even push the megamerge to the origin.
But why would I do that with git anyway ? My local branch is what I'm working of, if I'm not ready to push, why would I ? I can as you say just work off it..
And when I'm ready to push, I prep my commit, because I'm expecting it to be immutable and pulled by others 'as-is'. Again, I must be missing something. I think the tool is just not for me, yet at least.
Replies
I've often found myself needing to work on two features at once, esp. where one has a dependency on the other. Maybe that branch is the real goal, and the other branch is an independent chunk of work that the feature needs.
Both get iterated on, because it's hard to know everything about a feature before it's done; maybe you find bugs that need fixing, or you realise you were missing something.
Rebasing the dependent branch onto the tip of the other branch gets you there, but as a workflow it's not pleasant, especially if you're not the only person working on the features... It's a recipe for conflicts, and worse that rebased branch conflicting with another person's view of it.
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!)
Another example is that there is this simple monorepo that holds both the latest _BlaJS_ frontend and the backend API.
You are working on stuff in the backend, but it sure would be nice to see it in the frontend so you jury rig something in the frontend to display your work as well as some console.log() commands. Then you forget to revert changes to the frontend before pushing the branch.
In jj you would start with these as separate branches. Then you work on a merge of these. Then you use the absorb command to auto-move the code you are working on to the correct branch or you squash the changed files to the branch. Then you can push the backend branch to server and PR it. Then you throw away the frontend branch or just leave it there so you can use it in a future feature.
A real case from my work. I had to work on an old Python project that used Poetry and some other stuff that was just not working correctly on my computer. I did not want to toucj the CD/CI pipeline by switching fully to uv. But I created a special uv branch that moved my local setup to uv. Then went back up the tree to main and created a feature branch from there. Merged them together and worked out from that branch moving all the real changes to the feature branch. Now whenever I enter that project I have this uv branch that I can merge in with all the feature branches to work on them.