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

91–100 of 175 posts

Re: Jujutsu megamerges for fun and profit

#91

Post by chrishill89 »

Sometimes I have several pull requests to review and none of them have any meaningful overlap (e.g. they touch code in different places, no apparent risk of overlap). So I've started making integration branches to test all of them in one go. But then I sometimes find things to improve upon. Then I might make a few commits on top of that. And then later I have to manually move them to the correct branch. I might also remove them from the integration branch, but git-rebase(1) is likely to just drop them as already-applied.

My mind was a little blown when I read about the megamerge strategy in Steve Klabnik's tutorial.[1]

Yes, Jujutsu's approach of autorebasing changes is very nice. Now all I have to do is to try it myself.

† 1: https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...

Re: Jujutsu megamerges for fun and profit

#92

Post by conradludgate »

socalgal2 wrote: post #74
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…

I had a big feature I was working on. jj made it easy to split it into 21 small commits so I could give reviewers smaller things to review while I continued to work. It wasn't perfect and maybe git can do it all by itself but it's not my experience. In other words, I effectively was working on one thing, but at a quicker easier pace.

I've been doing this in git for years. Interactive rebasing isn't that scary. At work we have a very big stacked PR culture on github using native git

Re: Jujutsu megamerges for fun and profit

#93

Post by nchmy »

nvahalik wrote: post #11
taberiand wrote: post #8

How does the megamerge handle the case where two included branches overlap in changes and a new commit is made that applies to the overlap?

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?

Re: Jujutsu megamerges for fun and profit

#94

Post by vaylian »

One of the golden rules of git is: Don't rewrite public history (for example by rebasing and force-pushing already published commits). The article hints at immutable and mutable commits (https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...) but I am unsure about how fundamental this protection is. I don't want to ruin my co-worker's day by accidentally rewriting public history.

Re: Jujutsu megamerges for fun and profit

#95

Post by jnpnj »

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…

Depending on people workflow/mindset we often face stacked branches, lots of fixup commits, and over the years new git commands and tricks emerged to deal with that but not in cohesive way I guess. JJ seems (I only tried it a short while long ago) to address just that.

Re: Jujutsu megamerges for fun and profit

#96

Post by edu »

anthrofract wrote: post #70
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 stick to basic workflows most of the time, and it's still much better.

I concur, seems that lately we’ve collectively forget about the KISS principle.

Re: Jujutsu megamerges for fun and profit

#97

Post by baq »

SOLAR_FIELDS wrote: post #76
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…

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…

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.

Re: Jujutsu megamerges for fun and profit

#98

Post by jamienicol »

vaylian wrote: post #94

One of the golden rules of git is: Don't rewrite public history (for example by rebasing and force-pushing already published commits). The article hints at immutable and mutable commits ( https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an... ) but I am unsure about how fundamental this protection is. I don't want to ruin my co-worker's day by accidentally rewriting public history.

There's a configurable setting for which changes are marked as immutable. The default works perfectly for my workflow (pull-only from upstream, rewrite and push freely to my fork). other workflows may presumably need to tweak it

https://www.jj-vcs.dev/latest/config/#set-of-immutable-commi...

Re: Jujutsu megamerges for fun and profit

#99

Post by baq »

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…

> I do not understand the appeal of the workflow of working on separate things in parallel, then splitting it off into branches/commits.

Your repo is small and/or your CI is fast. You’ll understand in a big repo or when CI has to run overnight to get you results.

Re: Jujutsu megamerges for fun and profit

#100

Post by dwroberts »

SOLAR_FIELDS wrote: post #76
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…

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

Post reply on HN