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

121–130 of 175 posts

Re: Jujutsu megamerges for fun and profit

#121

Post by rstuart4133 »

conradludgate wrote: post #92
socalgal2 wrote: post #74

Earlier quoted context omitted.

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

> I've been doing this in git for years.

You've missed a crucial detail.

You've both been doing it, but only one of you was using a tool that needed rebases to pull it off.

Re: Jujutsu megamerges for fun and profit

#122

Post by rstuart4133 »

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.

Rewriting immutable commits is only "fundermental" if it's enforced upstream. You can always break the rule locally.

That said, jj will warn you if you try to edit an immutable commits, and you can configure what it considers immutable.

Re: Jujutsu megamerges for fun and profit

#123

Post by rstuart4133 »

krupan wrote: post #73

I reluctantly stopped using mercurial 10 or so years ago, and reading this brings a little tear to my eye. Mercurial was just about where jj seems to be now. It had revsets. It had just gotten the concept of mutable and immutable commits. It had absorb. It had bookmarks. It never had an "index". The commands had human readable options like I see in this post. It could work with git repositories. Man I miss it. I'm he…

According to the guy who wrote JJ, he copied all the ideas you mentioned from hg. That included a lot of ideas from hg's add ons. So the similarities are no accident. But then he added a twist - he didn't just delete the index, he dropped "hg commit" as well.

I can't see it going anywhere. It is in many ways "just" a different porcelain for git. The plumbing is the same. It's also safer to use: no JJ command can lose data another JJ command can't recover.

Re: Jujutsu megamerges for fun and profit

#124

Post by [deleted] »

chrishill89 wrote: post #103
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…

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…

[deleted]

Re: Jujutsu megamerges for fun and profit

#125

Post by chrishill89 »

chrishill89 wrote: post #103
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…

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.

Re: Jujutsu megamerges for fun and profit

#126

Post by rstuart4133 »

nozzlegear wrote: post #49
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.

I've found agents like Claude are absolute ass at fixing any halfway complex merge conflict. I won't trust them to do it.

You trust Claude (or any AI) to do anything right? The odds are good - but never 100%.

That said, "jj new -A @", get Claude to do it's thing, "jj squash" is going to be pretty safe.

Re: Jujutsu megamerges for fun and profit

#127

Post by hansmayer »

stouset wrote: post #84
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 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...

Who posts about git? Its one of those tools that just work and don´t need hype.

Re: Jujutsu megamerges for fun and profit

#128

Post by dwattttt »

edu wrote: post #96
anthrofract wrote: post #70

Earlier quoted context omitted.

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.

It's easy to forget that what's "simple" is a function of what tools we have. And our familiarity with them.

Re: Jujutsu megamerges for fun and profit

#129

Post by locknitpicker »

surajrmal wrote: post #75
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…

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 managing this sort of workflow sounds like you are mitigating a problem whose root cause is something else.

To me it reads like praising a tool for how it streamlines deployments to production by skipping all tests and deployment steps. I mean, sure. But doesn't this mask a far bigger problem? Why would anyone feel the need to skip checks and guardrails?

Re: Jujutsu megamerges for fun and profit

#130

Post by hilariously »

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?

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.

Post reply on HN