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

131–140 of 175 posts

Re: Jujutsu megamerges for fun and profit

#131

Post by nvader »

lucianbr wrote: post #108
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…

> 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

Re: Jujutsu megamerges for fun and profit

#132

Post by chrishill89 »

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.

Let's say that this is obsolete for professional programming. Can't us hobbyists be left alone to our hobby by the LLM demoralization patrol?

Re: Jujutsu megamerges for fun and profit

#133

Post by dwattttt »

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.

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.

Re: Jujutsu megamerges for fun and profit

#134

Post by sobjornstad »

ehnto wrote: post #114
stouset wrote: post #84

Earlier quoted context omitted.

I don't get git. Every time it's posted people gush about how git enables some super complicated workflow that I can't wrap my head around. I have a simple edit/undo workflow in my editor that has served me well for decades so I guess I don't understand...

There is a limit to how far one needs to abstract personally. I don't layer my utensils for example, because a spoon is fit for purpose and reliable. But if I needed to eat multiple different bowls at once maybe I would need to. For my personal use case, git is fit for purpose and reliable, even for complex refactoring. I don't find myself in any circumstances where I think, gosh, if only I could have many layers of…

Even if you're working on one single thread of development, jj is easier and more flexible than git though. That it works better for super complicated workflows is just a bonus.

Re: Jujutsu megamerges for fun and profit

#135

Post by pythonaut_16 »

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.

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!)

Re: Jujutsu megamerges for fun and profit

#136

Post by dwb »

SOLAR_FIELDS wrote: post #80
surajrmal wrote: post #77

Earlier quoted context omitted.

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…

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.

Re: Jujutsu megamerges for fun and profit

#137

Post by quarkz14 »

umvi wrote: post #66

I don't get JJ. Every time it's posted people gush about how JJ enables some super complicated workflow that I can't wrap my head around. I have a simple feature branch/rebase workflow in git that has served me well for decades so I guess I don't understand why I would want to complicate things with (in this case) an "octopus merge/megamerge". Wouldn't that make it more difficult to reason about the repository/histor…

I didn't at first and let's be honest most of our workflow is within what you described, however in the era of AI assisted coding I found JJ more pragmatic. I can easily abandon or create new work without having to stash or commit etc. Another thing I really like about JJ it's undo, did I commit something and realised I forgot to add something? jj undo and undos the last operation. Not only my workflow is ergonomically more flexible because of JJ but also less forgiving without having to memorise a lot of git commands. And integrates with already git repos for smooth transition!

Re: Jujutsu megamerges for fun and profit

#138

Post by adrianmsmith »

quicksnap wrote: post #59
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…

From practical experience from using jj daily and having (disposable) mega merges: When I have discrete, separate units of work, but some may not merge soon (or ever), being able to use mega merges is so amazing. For example, I have some branch that has an experimental mock-data-pipeline thingy. I have yet to devote the time to convince my colleagues to merge it. But I use it. Meanwhile, I could be working on two dis…

> Because jj's conflict resolution is fundamentally better

I don't know jj well so its merge algorithm may well be better in some aspects but it currently can't merge changes to a file in one branch with that file being renamed in another branch. Git can do that.

https://github.com/jj-vcs/jj/issues/47

Re: Jujutsu megamerges for fun and profit

#139

Post by surajrmal »

dwroberts wrote: post #100
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 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.

Re: Jujutsu megamerges for fun and profit

#140

Post by bombcar »

dzaima wrote: post #120
maleldil wrote: post #117

Earlier quoted context omitted.

I've been using it in relatively the same way for a while now. The only meaningful changes were native support for `tug` and `absorb`, neither of which significantly changed my workflow.

eh, there have been a good amount of breaking changes. `-d`/`--destination` → `-o`/`--onto` (the former isn't yet deprecated though); deprecated `--allow-new` on push (or, forcibly making it the default for `--bookmark`); deprecated `jj bookmark track foo@bar` (and `jj bookmark track foo` having a really-weird system (I personally just call it broken, even though the behavior is intentional) of sometimes tracking the…

I think for a real neophyte jj will be fine especially when used with the git backend.

Someone who "knows enough to be dangerous" may be better served by sticking with the git happy-path.

Of course, if working with others you should use what they do until you're confident that you can switch without impacting them.

Post reply on HN