Comment by SOLAR_FIELDS
9 hours ago
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 the same day"
The jj lovers can go build their massive beautiful branches off in a corner, I'll be over here building an SDLC that doesn't require that.
Old man yells at cloud moment is over
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 upstream accepts it (if they ever call back).
I’m pretty sure that the Git For Windows project is managed as patches on top of Git. And I’ve seen the maintainer post patches to the Git mailing list saying something like, okay we’ve been using this for months now and I think it’s time that it is incorporated in Git.[1]
I’ve seen patches posted to the Git mailing list where they talk about how this new thing (like a command) was originally developed by someone on GitHub (say) but now someone on GitLab (say) took it over and wants to upstream it. Maybe years after it was started.
Almost all changes to the Git project need to incubate for a week in an integration branch called `next` before it is merged to `master`.[1] Beyond slow testing for Git project itself, this means that downstream projects can use `next` in their automated testing to catch regressions before they hit `master`.
† 1: Which is kind of a like a “megamerge”
> incorporated in Git.[1]
Dangling footnote. I decided against adding one and forgot to remove it.
It depends. We have pretty good review culture (usually same day rarely more than 24H), but some changes may need multiple rounds of review or might be have flaky tests that uncovers after a few hours. Also some work is experimental and not ready for pushing out for review. Sometimes I create a very large number of commits as part of a migration DND I can't get them all reviewed in parallel. It can be a lot of things. Maybe it happens more with monorepos.
All fair points, indeed I face each of the challenges you listed periodically myself. But it's never been often enough to feel like I need to seek out an entirely different toolchain and approach to manage them.
Well, fortunately Jujutsu isn’t an entirely different toolchain and/or approach. It’s one tool that’s git-compatible and is quite similar to it. But where it’s different, it’s (for me) better.
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 would you like git and not jj is beyond me, this must be something like two electric charges being the same and repelling themselves. It’s the same underlying data structure with a bit different axioms (conflicts allowed to be committed vs not; working tree is a commit vs isn’t).
Turns out these two differences combined with tracking change identity over multiple snapshots (git shas) allow for ergonomic workflows which were possible in git, just very cumbersome. The workflows that git makes easy jj also keeps easy. You can stop yelling at clouds and sleep soundly knowing that there is a tool to reach for when you need it and you’ll know when you need it.
> you don't have a culture where
Yeah, and? Not everyone is in control of the culture of the organization they work in. I suspect most people are not. Is everyone on HN CEOs and CTOs?
Temporarily embarrassed CEOs and CTOs
No, but there are a lot of them, and principal and staff engineers, and solo folks who would get to set the culture if they ever succeed.
A lot of people's taste making comes from reading the online discussions of the engineering literati so I think we need old folks yelling at clouds to keep us grounded.
I think the unspoken part is that the mess of commits is being produced by agents not people.
That’s why it’s always the same confusing hype when it’s discussed, because it’s AI/LLM hype effectively
I was in this situation long before llms came along. They may have exacerbated it a bit, but they are not the root cause.