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

161–170 of 175 posts

Re: Jujutsu megamerges for fun and profit

#161

Post by dwb »

seba_dos1 wrote: post #158
dwb wrote: post #136

Earlier quoted context omitted.

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.

Yeah, I've never used Jujutsu, but from what I've seen so far everything it does can be done with Git itself, just perhaps in a (sometimes significantly) less convenient way.

Sure, true, I would say "often significantly" though, to the extent that you would never bother doing half the things with git that you can do with Jujutsu because it's such a pain.

Re: Jujutsu megamerges for fun and profit

#162

Post by mi_lk »

SOLAR_FIELDS wrote: post #147
mi_lk wrote: post #115

Earlier quoted context omitted.

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 frame this as either/or? Those aren't the only two options. There are different types of "large" PR's. If I'm doing a 10,000 LOC refactor that's changing a method signature, that's a "large" PR, but who cares? It's the same thing being done over and over, I get a gist of the approach, do some sampling and sanity checks, check sensitive areas, and done. If I'm doing something more complex and storied to the point…

> If I'm doing something more complex and storied to the point it requires stacks with dependencies, then I'm questioning why I haven't split and chunked the thing into smaller PR's in the first place and having those reviewed.

It looks like you see stack PR as an inherent complex construct, but IMO splitting the implementation into smaller, more digestable and self-contained PRs is what stack PR is about

So if you agree that is a better engineering practice, then jj is only a tool that helps you do that without thinking too much about the tool itself

Re: Jujutsu megamerges for fun and profit

#163

Post by stouset »

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…

jj reduces mental overhead by mapping far more cleanly and intuitively to the way people tend to work.

This is a little weird at first when you’ve been used to a decade and a half of contorting your mental model to fit git. But it genuinely is one of those tools that’s both easier and more powerful. The entire reason people are looking at these new workflows is because jj makes things so much easier and more straightforward that we can explore new workflows that remove or reduce the complexity of things that just weren’t even remotely plausible in git.

A huge one for me: successive PRs that roll out some thing to dev/staging/prod. You can do the work all at once, split it into three commits that progressively roll out, and make a PR for each. This doesn’t sound impressive until you have to fix something in the dev PR. In git, this would be a massive pain in the ass. In jj, it’s basically a no-op. You fix dev, and everything downstream is updated to include the fix automatically. It’s nearly zero effort.

Another is when you are working on a feature and in doing so need to add a capability to somewhere else and fix two bugs in other places. You could just do all of this in one PR, but now the whole thing has to b reviewed as a larger package. With jj, it’s trivial to pull out the three separate changes into three branches, continue your work on a merge of those three branches, and open PRs for each separate change. When two of them merge cleanly and another needs further changes, you just do it and there’s zero friction from the tool. Meanwhile just the thought of this in git gives me anxiety. It reduces my mental overhead, my effort, and gives overburdened coworkers bite-sized PRs that can be reviewed in seconds instead of a bigger one that needs time set aside. And I don’t ever end up in a situation where I need to stop working on the thing I am trying to do because my team hasn’t had the bandwidth to review and merge my PRs. I’ve been dozens of commits and several stacked branches ahead of what’s been merged and it doesn’t even slightly matter.

Re: Jujutsu megamerges for fun and profit

#164

Post by locknitpicker »

seba_dos1 wrote: post #157
locknitpicker wrote: post #129

Earlier quoted context omitted.

> 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 mana…

Some will say that it's a "red flag", others will say that those saying it's a red flag lack the experience of working on diverse set of projects with various needs and requirements.

> Some will say that it's a "red flag", others will say that those saying it's a red flag lack the experience of working on diverse set of projects with various needs and requirements.

What if those who call out red flags actually do so based on experience,particularly in understanding how and why red flags are red flags and why it's counterproductive to create your own problems?

I mean, if after all your rich experience working on diverse set of projects with various needs and requirements, your answer to repeatedly shooting yourself in the foot is that you need a tool to better aim around your toes... What does it say about what lessons you draw?

Re: Jujutsu megamerges for fun and profit

#165

Post by locknitpicker »

eru wrote: post #90
locknitpicker wrote: post #82

Earlier quoted context omitted.

> That definitely includes mercurial etc. People tried mercurial. They went back to git.

Some did, sure. I made a more limited claim: you can convert back and forth between mercurial and git.

> Some did, sure.

Not some. I mean, even the few source code repository services that supported mercurial started dropping it.

See Bitbucket's announcement:

https://www.atlassian.com/blog/bitbucket/sunsetting-mercuria...

> According to a Stack Overflow Developer Survey, almost 90% of developers use Git, while Mercurial is the least popular version control system with only about 3% developer adoption. In fact, Mercurial usage on Bitbucket is steadily declining, and the percentage of new Bitbucket users choosing Mercurial has fallen to less than 1%.

Re: Jujutsu megamerges for fun and profit

#166

Post by LoganDark »

icorbrey wrote: post #20
LoganDark wrote: post #15

I saw Jujutsu on HN a few days ago and gave it a try. I picked a bunch of it up in just a couple hours and a couple days later I've completely switched to it for all my projects, it's not even close. Git is dead to me. I just wish Jujutsu supported git tags rather than only supporting bookmarks as branches. And I also wish that Jujutsu supported preserving commit dates during rebases. One of my absolute favorite thin…

Re: commit dates, fundamentally those always change when rebasing because you're rewriting the commit object, but we don't touch the author date unless you explicitly reset it with metaedit

I'm not sure which date GitHub displays, but whenever I change something early in history, the entire repo loses every date.

Re: Jujutsu megamerges for fun and profit

#167

Post by vaylian »

taberiand wrote: post #112
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.

Don't rewrite shared public history It's ok to force-push a branch that only you have worked on (and even in the case of others working on the same branch it can be fine as long as you communicate with them)

I agree. This is a valid exception.

Re: Jujutsu megamerges for fun and profit

#168

Post by nchmy »

nvahalik wrote: post #144
nchmy wrote: post #93

Earlier quoted context omitted.

Could you please elaborate on how you do this?

If you have a dependency tree like this: / A \ -- B - Megamerge \ C / There is nothing stopping you from doing this: / A - D \ -- B ----- - Megamerge \ C - E / (Edit, or even this:) / A - D \ -- B ----- - Megamerge \ C ----/ \ E / Where E stacks on C and D stacks atop A. In the case above, A-E are revsets of either 1 or more commits. JJ doesn't care if they are or not. You'd generally bookmark the revset on the final…

Thanks!

Re: Jujutsu megamerges for fun and profit

#169

Post by icorbrey »

domysee wrote: post #156

It sounds like the same workflow that GitButlers UI has. Can anyone with more knowledge than me confirm or deny that?

If you inspect a GitButler repo with JJ you can see that it's topologically identical actually! https://bsky.app/profile/isaaccorbrey.com/post/3m33wrahz4222

Re: Jujutsu megamerges for fun and profit

#170

Post by uhhhd »

skydhash wrote: post #48
uhhhd wrote: post #37

Earlier quoted context omitted.

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…

A lot of words to say "LLMs are good for this, trust me bro!" You're bashing the old way, but you do not provide any concrete evidence for any of your points. > The unit of work is no longer “branches” or “commits,” it’s intent. Insert . Branching is always about "I want to try to implement this thing, but I also want to quickly go back to the main task/canonical version". Committing is about I want to store this ver…

I think we’re talking past each other. My point isn’t that jj is bad. It’s that it’s solving problems that are rapidly becoming irrelevant.

Tools like git and jj exist to help humans manage state: branches, commits, rebases, conflicts, history curation. That whole model assumes a human is directly manipulating and reasoning about the codebase.

With LLMs in the loop, that assumption breaks. I don’t need to think in terms of branches or commits. I describe intent, and the model handles the mechanics of editing, reconciling, and producing a coherent result. Source control becomes an implementation detail of the toolchain, not something I actively operate.

jj is an improvement over git for humans, but that’s exactly why it feels like a local maximum. It refines a workflow that is already being abstracted away.

I’m not saying version control disappears. I’m saying it moves down a layer, the same way memory management or instruction scheduling did. When that happens, optimizing the human interface to it matters a lot less.

Post reply on HN