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

51–60 of 175 posts

Re: Jujutsu megamerges for fun and profit

#51

Post by surajrmal »

uhhhd wrote: post #37
MeetingsBrowser wrote: post #24

Earlier quoted context omitted.

I disagree. Easily reviewing and combining multiple streams of parallel work is more valuable than ever.

You don’t need jj for this anymore. The whole premise of optimizing human workflows around source control is becoming obsolete. When LLMs are driving development, source control stops being an active cognitive concern and becomes a passive implementation detail. The unit of work is no longer “branches” or “commits,” it’s intent. You describe what you want, the model generates, refactors, and reconciles changes across…

There are a lot of assumptions baked into your assessment. We are not at the point where manual workflows are obsolete. Maybe it is for folks who work on web apps, but it's certainly not the case for many others. AI Agents are constantly making mistakes and need oversight. Things have gotten dramatically better, but not enough for me to trust it to not create a terrible mess.

Re: Jujutsu megamerges for fun and profit

#52

Post by KPGv2 »

faangguyindia wrote: post #36
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. imo, isn't it better to fully focus on one thing at a time, even if it is "simple"? because agents are slow. I use SOTA model (latest opus/chatgpt) to first flesh out all the work. since a lot of agent harness use some black magic, i use this workflow 1. Collect all issues 2. Make a…

"because AI" isn't really a good answer since JJ was not created for AI, and most people who use JJ aren't just AI bots.

Re: Jujutsu megamerges for fun and profit

#53

Post by KPGv2 »

paradox460 wrote: post #47
sukit wrote: post #25

Been trying to get into jj lately, but I rely a lot on VS Code's git gutter to review changes as I code. Doesn't look like jj has an equivalent in VS Code. Anyone got tool recommendations?

There are a number of jj plugins for vsc. VisualJJ and Jujutsu Kaizen are probably the two most popular https://www.visualjj.com/ https://github.com/keanemind/jjk

> jjk

what's next, "oh! my gitess"? "chainsvn man"?

Re: Jujutsu megamerges for fun and profit

#55

Post by duskdozer »

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 don't think I really understand the way jujutsu is doing this, but if it's what I think, one example would be that you realize while working that some changeset is getting too big and makes sense to split it. So B would depend on A and be on top eventually, but you don't know the final form of B until you've finished with both. I've always just done this with rebasing and fixups, but I could see it being easier if you could skip that intermediate step.

Re: Jujutsu megamerges for fun and profit

#56

Post by BeetleB »

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…

As a jujutsu user, I don't disagree. I can see the appeal of doing a megamerge, but routinely working on the megamerged version and then moving the commits to the appropriate branch would be the exception, not the norm.

I gather one scenario is: You do a megamerge and run all your tests to make sure new stuff in one branch isn't breaking new stuff in another branch. If it does fail, you do your debug and make your fix and then squash the fix to the appropriate branch.

Re: Jujutsu megamerges for fun and profit

#57

Post by quicksnap »

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.

And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.

When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.

I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.

The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!

Re: Jujutsu megamerges for fun and profit

#58

Post by quicksnap »

ksymph wrote: post #43

Semi off-topic, but does anyone know of good resources for jj that don't assume git knowledge? Steve's and others are high quality, but often things are explained in terms of git equivalents or describe workflows that I struggle to fully understand the purpose of, as someone who knows only the barest basics of git necessary to work on personal projects. If none exist, I think there's a great opportunity there, for an…

I'm not immediately aware. There's a certain amount of git-ness embedded in it with it being a DAG, having commits, and being compatible with git remotes. And, since the industry still runs on git, most people will need to learn it somewhat, anyway.

Re: Jujutsu megamerges for fun and profit

#59

Post by quicksnap »

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 distinct things that can merge separately, but I would like to use Thing A while also testing Thing B, but ALSO have my experimental things merged in.

Simply run `jj new A B C`. Now I have it all.

Because jj's conflict resolution is fundamentally better, and rebases are painless, this workflow is natural and simple to use as a tool

Re: Jujutsu megamerges for fun and profit

#60

Post by quicksnap »

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 have been using Claude for 95% of the mechanical coding for months, and jj has proven to be more relevant than not for me. Because it is a better VCS tool than git, it allows to work with the firehose of commits much more seamlessly.
Post reply on HN