Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jujutsu at Google [video]

youtube.com

Post reply on HN
Print view View original

121–130 of 212 posts

Re: Jujutsu at Google [video]

#121

Post by verdverm »

steveklabnik wrote: post #117
verdverm wrote: post #115

Earlier quoted context omitted.

The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no" I'm going to take the docs for what they say about support over an HN comment

You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.

right, but then I'm using git, not jj, so why jj?

Why do people believe it's going to replace git if it won't do basic things we need. Why is it hard for jj to create a tag?

Re: Jujutsu at Google [video]

#122

Post by steveklabnik »

verdverm wrote: post #121
steveklabnik wrote: post #117

Earlier quoted context omitted.

You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.

right, but then I'm using git, not jj, so why jj? Why do people believe it's going to replace git if it won't do basic things we need. Why is it hard for jj to create a tag?

It’s not. It’s that there’s no inherent advantage to doing it natively when it works just fine via git. There’s more important things to do first, like many of the things on your list.

It’ll get there! Early days.

Re: Jujutsu at Google [video]

#123

Post by danpalmer »

kyrra wrote: post #8
barlog wrote: post #3

FYI: Linux only GA planned for early 2026

This talk is focused on JJ within Google. This is a Google-internal only GA. JJ is available externally just fine. Google is mainly a linux-dev shop, with all other platforms being second-class citizens.

Furthermore, many engineers at Google work on Macs, some even on Windows, but the actual code runs on a Linux box in a datacenter. I use a Mac, my editor is local, my terminal is local, but it's all SSH/remote to the linux box, so I've never needed jj to run on my Mac. This, or a high powered Linux desktop, are the norm.

The main exceptions to this are devs who work on iOS or macOS software, who will sometimes do local builds on their physical machine. They would benefit from jj support, but there are more hoops to jump through, and the jj port will most likely be less about running on macOS and more about jj supporting the weird ways in which source is accessed.

Re: Jujutsu at Google [video]

#124

Post by aidenn0 »

verdverm wrote: post #112
aidenn0 wrote: post #87

Earlier quoted context omitted.

Having used git submodules, I see a lack of them as a feature. I honestly think that a script that checks out a specific commit from an external repository, combined with adding the path to the .gitignore is strictly better than submodules.

sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all) Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those

git doesn't do everything that SVN does, so I don't think that's true.

Re: Jujutsu at Google [video]

#125

Post by koiueo »

Agingcoder wrote: post #96
koiueo wrote: post #81

Earlier quoted context omitted.

There are simply people who've rtfm and people who haven't

The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way. It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.

That's really unexpected. To me, git documentation was one of the best cleanest official docs I've ever read.

Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a good head start) if you decide to develop your own jujutsu or kurutu or whutuvur.

[0] https://git-scm.com/book/en/v2

Re: Jujutsu at Google [video]

#126

Post by verdverm »

gpm wrote: post #116
verdverm wrote: post #114

Earlier quoted context omitted.

A is the remote, B is a coworkers commit, C is mine (iiuc jj uses stacked commits instead of branches) Let's remove the merge conflict and keep the commits in alphabetical order B pushes a breaking change, I push a commit to C without knowing. Are my builds and PRs now at the mercy of changes and events outside of my control? (my hunch is that there are a bunch of confusing situations in jj like git, and that being d…

You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it. > iiuc jj uses stacked commits instead of branches Locally jj doesn't really use branches, you can just create a commit o…

We don't use rebase at all, it's forbidden.

Since jj does not have branches, it sounds like we are forced into the rebase environment?

With git, I can push my changes without a force, regardless of what the work I build on does

I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding activities. CUE suffers from this as well. The biggest pushback I hear is about being able to wrap their heads around it. Devs seem to be largely burnt out on tooling changes right now, we left that hype cycle as the ai/agent cycle was emerging

> I don't believe there's any circumstance where your work is silently rebased on top of other work, or anything else that fits this description.

This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...

Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?

Re: Jujutsu at Google [video]

#127

Post by ilyagr »

Lanedo wrote: post #2

The full JJ Con playlist is: https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6y...

See also https://github.com/jj-vcs/jj/wiki/JJ-Con-2025 for a list of all the talks, their slides, and some additional notes. I think the slides are also linked from youtube, but the website definitely has them.

Re: Jujutsu at Google [video]

#128

Post by verdverm »

aidenn0 wrote: post #124
verdverm wrote: post #112

Earlier quoted context omitted.

sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all) Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those

git doesn't do everything that SVN does, so I don't think that's true.

The development world is much different and entrenched than it was when the move from svn -> git happened. Think of all the tooling, integrations, and automation we use these days. That was not happening 15+ years ago. I don't think svn as an analogy holds much water, tbh

Re: Jujutsu at Google [video]

#129

Post by verdverm »

kubanczyk wrote: post #76
dakiol wrote: post #18

I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…

> So, what am I missing? Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.

What if we don't use git rebase at all? What does jj have to offer us?

Re: Jujutsu at Google [video]

#130

Post by phyrex »

jeffbee wrote: post #39
ffsm8 wrote: post #28

Earlier quoted context omitted.

> terabytes of source code You sure that exists? Git repositories that contain terabytes of source code? I could imagine a repo that is terabytes but has binaries committed or similar... But source code?

git could never, but piper at google is way over that figure. Way, way over.

Microsoft has actually done a lot of work to scale got to large repos
Post reply on HN