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

The creator of Jujutsu has joined ERSC

ersc.io

Post reply on HN
Print view View original

91–100 of 282 posts

Re: The creator of Jujutsu has joined ERSC

#91

Post by steveklabnik »

underdeserver wrote: post #85
steveklabnik wrote: post #13

Earlier quoted context omitted.

Thanks! Martin left Google for this, yes.

Wasn't it partially owned by Google? Or are they just a contributer now?

I like to compare Google and jj to Mozilla and Rust: Google employed Martin and some other maintainers, but it's always been an OSS project under the Apache 2.0 license.

That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.

(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)

Re: The creator of Jujutsu has joined ERSC

#92

Post by saghm »

pwdisswordfishq wrote: post #36
steveklabnik wrote: post #19

Earlier quoted context omitted.

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site. While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not po…

The enterprise sounds accurate. You mention performance issues with Git, but there are performance issues with this blog post.

If the worst thing you can say about a git hosting provider is that the performance of their blog is worse than the performance of their git servers, I think they're probably doing an okay job.

Re: The creator of Jujutsu has joined ERSC

#93

Post by figbert »

steveklabnik wrote: post #7
tensegrist wrote: post #5

what a lovely website

Thank you! We liked our old look, but one funny thing about how things are going in the world: our old color scheme was too close to what happens when you ask Claude to generate a site, and so even though we paid a human to build it, we didn't want to communicate slop, especially because that's not what we did! Nick Noble is our designer, he put in a bunch of work on this, and I really like it too.

Nick is great! Met him at the Recurse Center. Brilliant designer.

Re: The creator of Jujutsu has joined ERSC

#94

Post by zmodem »

rirze wrote: post #16
fallat wrote: post #12

Someone will have to explain the value proposition to me... We have git. jujutsu works with git. git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git). Thus, jujutsu is a UX / new steering wheel. ERSC is trying to be a GitHub competitor with what surplus value? Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the down…

I might be mistaken, but I always figured the end goal for jujitsu was to use its own backend. Supporting git-colocation seems like a compatibility case to bring users over. If I had to guess, then I would say ERSC is trying to build a `jj` forge based on this new hire and that would be amazing imo.

Maybe like some kind of https://jjhub.com :-)

Re: The creator of Jujutsu has joined ERSC

#95

Post by kps »

drsouth wrote: post #65
jph wrote: post #17

Jujutsu is a better smarter git. It's a great convergence of better UX, plus more expressive, plus easier to use. If you haven't tried jj yet, take it for a spin and see how you like it.

How does it compare to Mercurial? And why would it get more traction than Mercurial?

Others have answered about traction. As a one-time Mercurial user, I think the single most significant addition is first-class conflicts, so that dealing with them doesn't stop the world but can be deferred until I'm working on a particular conflicted change. (That also eliminates the need to ‘evolve’.) Easy undo is also nice.

Re: The creator of Jujutsu has joined ERSC

#96

Post by lucasoshiro »

fallat wrote: post #12

Someone will have to explain the value proposition to me... We have git. jujutsu works with git. git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git). Thus, jujutsu is a UX / new steering wheel. ERSC is trying to be a GitHub competitor with what surplus value? Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the down…

> jujutsu works with git.

Just like TypeScript with JS, QUIC with UDP, GraphQL with HTTP, Android with Linux, and so on

> git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git)

Replace "jujutsu"/"git" by "typescript"/"js", "quic/udp", etc and you'll understand.

Re: The creator of Jujutsu has joined ERSC

#97

Post by lucasoshiro »

drsouth wrote: post #65
jph wrote: post #17

Jujutsu is a better smarter git. It's a great convergence of better UX, plus more expressive, plus easier to use. If you haven't tried jj yet, take it for a spin and see how you like it.

How does it compare to Mercurial? And why would it get more traction than Mercurial?

Jujutsu is built on top of Git, so it can benefit tools in the same ecosystem (forges, CIs, code quality tools, IDEs, plugins, etc).

I have only played a little with jj and hg, but I felt that jj has a more modern UX, learning from years of Git existence (and even influencing Git, like the new `git history` command [1]). On the other hand, hg was created in the same month as Git, both trying to improve the experience of the VCSs available at the time (april 2005).

[1] https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...

Re: The creator of Jujutsu has joined ERSC

#98

Post by gritzko »

Arainach wrote: post #80
drsouth wrote: post #65

Earlier quoted context omitted.

How does it compare to Mercurial? And why would it get more traction than Mercurial?

Git already won through Github, the Linux kernel, and other important projects. Even if you like Mercurial's syntax better (I do) and wish it won (I do), that battle was over many years ago. jj's data store is git. You can use jj while other people on your project just use git. There's no migration of data or history. You can use Github and all of the various git tooling that exists today. As such, the initial cost o…

It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics.

Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.

Re: The creator of Jujutsu has joined ERSC

#99

Post by jdc-pub »

steveklabnik wrote: post #19
fallat wrote: post #12

Someone will have to explain the value proposition to me... We have git. jujutsu works with git. git can do everything jujutsu can do (otherwise, jujutsu couldn't work with git). Thus, jujutsu is a UX / new steering wheel. ERSC is trying to be a GitHub competitor with what surplus value? Don't get me wrong, GitHub has a slew of its own problems, but I have not seen any commentary on how ERSC addresses any of the down…

We'll be saying more about this very soon, but the short version is this: we are not building a GitHub competitor in the way that SourceHut or Codeberg are. We are building infrastructure for enterprises, not a social coding site. While jj works with git, it doesn't have to. jj has the ability to work with many backends. Git is the popular one in the open source world, but that doesn't mean that other ones are not po…

I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.

But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.

I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?

P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.

[1] https://jdc.pub/posts/git-jj

Re: The creator of Jujutsu has joined ERSC

#100

Post by kps »

sshine wrote: post #42
minraws wrote: post #35

jj is one of the few new devtools I was quite frustrated with while starting out but could see the value so stuck around and man is it so nice. For anyone curious the big thing with jj is you can undo. Basically if you were running a rebase and bungled a commit sha or branch name, no worries undo your way out, if you forgot to push but abandoned a commit not issues undo it. Same with all jj commands. Delta db takes t…

Are you saying push + undo = unpush?

jj itself doesn't have a native ‘push’. `jj git push` and `jj piper upload`¹ operate on external systems that don't necessarily support undoing arbitrary operations. Pure speculation, but if I were ESRC I'd make my backend handle it (subject to enterprise audit policies).

¹ https://drive.google.com/file/d/1dVzug1lHoOxdbFu8gcCJCu-G_uV...

Post reply on HN