Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu megamerges for fun and profit

isaaccorbrey.com

Post reply on HN
Print view View original

141–150 of 175 posts

Re: Jujutsu megamerges for fun and profit

#141

Post by JonGretarB »

bilekas wrote: post #113
jychang wrote: post #106

Earlier quoted context omitted.

Did you read the article? > Basically, in the megamerge workflow you are rarely working directly off the tips of your branches. Instead, you create an octopus merge commit (hereafter referred to as “the megamerge”) as the child of every working branch you care about. This means bugfixes, feature branches, branches you’re waiting on PRs for, other peoples’ branches you need your code to work with, local environment se…

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

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.

Re: Jujutsu megamerges for fun and profit

#142

Post by JonGretarB »

b1temy wrote: post #35

I do not understand the appeal of the workflow of working on separate things in parallel, then splitting it off into branches/commits. imo, isn't it better to fully focus on one thing at a time, even if it is "simple"? I imagine if I follow this workflow, I might accidentally split it off in a way that branch A is dependent on some code changes in branch B, and/or vice versa. Or I might accidentally split it off in a…

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 touch 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.

Re: Jujutsu megamerges for fun and profit

#143

Post by JonGretarB »

uhhhd wrote: post #23

I love this stuff as a hobbyist, but professionally I can't help but think this is all obsolete in the age of agent-driven development. I wish jj was around a decade ago.

Oh I would say that jj is exactly the kind of VCS needed for agentic workflows.

Anonymous branches. Easy to move things around. Always succeeding merges. Megamerges. Worktrees not bound to branches.

Re: Jujutsu megamerges for fun and profit

#144

Post by nvahalik »

nchmy wrote: post #93
nvahalik wrote: post #11

Earlier quoted context omitted.

The mega merge wouldn't handle that based on the way the article shows. You COULD have a revset that includes stacked changes, though. That does work and is what I currently do.

Could you please elaborate on how you do this?

If you have a dependency tree like this:

       / A \
      -- B - Megamerge 
       \ C /
There is nothing stopping you from doing this:

       / A - D \
      -- B ----- - Megamerge 
       \ C - E /
(Edit, or even this:)

       / A - D \
      -- B ----- - Megamerge 
       \ C ----/
          \ E /
Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final "commit" as the pointer.

           / features/add-widgets
          /  / features/add-widget-integration
       / A - D \
      -- B ----- - Megamerge 
       \ C - E /
          \   \ feature/add-new-page
           \ feature/rework-navigation
In the example above, let's say you rework the navigation. You could have it exist alongside the navigation rework, but changes are you don't want to do the work twice. You just say "hey, this depends on the nav rework" and so it's there inside of the repo.

The thing is there is another way to do this where you end up with 4 different parents in a megamerge and your nav rework touches the megamerge and your new page is yet another revset is just a fork off of it. But yeah... JJ gives you a lot of flexibility in this manner.

Re: Jujutsu megamerges for fun and profit

#145

Post by Shish2k »

locknitpicker wrote: post #82
eru wrote: post #72

Earlier quoted context omitted.

> Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state. Btw, the risk of trying out other modern version control systems is nearly as low: most of them are compatible with git and you can convert back and forth. That definitely includes mercurial etc.

> That definitely includes mercurial etc. People tried mercurial. They went back to git.

I tried Sapling (Facebook's fork of mercurial with more polished git-compatibility layers) and never looked back for any of my own projects.

I recently started a new job where the vanilla git CLI is the only git frontend installed on company servers, and the regressions in user-experience are painful :(

Re: Jujutsu megamerges for fun and profit

#146

Post by SAI_Peregrinus »

locknitpicker wrote: post #129
surajrmal wrote: post #75

Earlier quoted context omitted.

If you wrangle a lot of in flight changes that are not yet merged into your teams primary git repo, it's very helpful. I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. Placing them all into one branch can work but it's a lot less ergonomic in many ways. jj makes my life simpler because it accommodates my workflow in a way git doesn't. Honest…

> I have some 10-30 changes in various states at any time. Sometimes they have dependencies on each other sometimes they don't. This is the sort of scenario that leans me towards thinking tools are being praised by how they support major red flags in development flows. Having dozens of changes in flight in feature branches that may or may not be interdependent is a major red flag. Claiming that a tool simplifies mana…

Take Linux: they've got a "super-long-term-support" branch, a "long-term-support" branch, a "stable" branch, and the next "stable" branch. Stable is supported until the release of the next "stable" & 3 months after that, with (usually) 2-6 months between stable releases. "long-term-support" branches are supported for about 5 years, "super-long-term-support" for a few years after that. So there can be up to 4 released branches actively supported at any given time, ignoring any feature branches.

Re: Jujutsu megamerges for fun and profit

#147

Post by SOLAR_FIELDS »

mi_lk wrote: post #115
SOLAR_FIELDS wrote: post #76

Earlier quoted context omitted.

Every time I hear about this megamerge and stacked pr nonsense, it just smells to me. Like, why does your engineering organization have a culture where this sort of nonsense is required in the first place? Anytime I see articles like this gushing about how great tool XYZ is for stack merging and things like that, all I hear is "you don't have a culture where you can get someone looking at and mainlining your PR on th…

I'd really like to hear your argument about when single large PR is better than stacked PRs from both PR author and reviewers' perspectives

Why frame this as either/or? Those aren't the only two options.

There are different types of "large" PR's. If I'm doing a 10,000 LOC refactor that's changing a method signature, that's a "large" PR, but who cares? It's the same thing being done over and over, I get a gist of the approach, do some sampling and sanity checks, check sensitive areas, and done.

If I'm doing something more complex and storied to the point it requires stacks with dependencies, then I'm questioning why I haven't split and chunked the thing into smaller PR's in the first place and having those reviewed. Ultimately the code still has to get reviewed, so often it's about reframing the mindset more than anything else. If it organizationally slows me down to the point that chunking the PR into smaller components is worse than a stacked-pr like approach, I'm not questioning the PR structure, I'm questioning why I'm being slowed down organizationally. Are my reviews not picked up fast enough? Is the automated testing situation not good enough? The answer always seems to come back to the process and not the tooling in these scenarios.

What problem does the stacked PR solve? It's so I can continue working downstream while someone else reviews my unmainlined upstream code that it depends on. If my upstream code gets mainlined at a reasonable rate, why is this even a problem to be solved? It also implies that you're only managing 1-3 major workstreams if you're getting blocked on the feature downstream which also begs the question, why am I waterfalling all of my work like this?

Fundamentally, I still have to manage the dependency issue with upstream PR's, even when I'm using stacked PR's. Let's say that an upstream reviewer in my stacked PR chain needs me to change something significant - a fairly normal operation in the course of review. I still have to walk down that chain and update my code accordingly. Having tools to slightly make that easier is nice, but the cost benefit of being on a different opt in toolchain that requires its own learning curve is questionable.

Re: Jujutsu megamerges for fun and profit

#148

Post by [deleted] »

chrishill89 wrote: post #125
chrishill89 wrote: post #103

Earlier quoted context omitted.

Not all software is developed by one software organization. Programs to manage “stacks of patches” go back decades. That might be hundreds that have accumulated over years which are all rebased on the upstream repository. The upstream repository might be someone you barely know, or someone you haven’t managed to get a response from. But you have your changes in your fork and you need to maintain it yourself until ups…

> incorporated in Git.[1] Dangling footnote. I decided against adding one and forgot to remove it.

[deleted]

Re: Jujutsu megamerges for fun and profit

#149

Post by jiggunjer »

Strange advice not to push the mega merge. It's what I call my release branch.

One thing I like is there's many ways to achieve the same result. E.g. author uses a fancy rebase to graft a new branch between trunk and merge point. I could do the same by: 1) rebase -s onto trunk, 2) merge new branch with mega merge, 3) squash old megamerge upwards into new merge. No cryptic revset needed.

Post reply on HN