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

241–250 of 283 posts

Re: The creator of Jujutsu has joined ERSC

#241

Post by yencabulator »

pjmlp wrote: post #187
saghm wrote: post #84

Earlier quoted context omitted.

I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint (lots of inconsistent naming of things and somewhat leaky abstractions), and that Mercurial faced an uphill battle in large part because it lacked compatibility with what people were already using. I haven't used Mercurial, but from what I've heard quite a lot of how jj does thing…

As a Mercurial fanboy, git took off thanks to being from Linus, and a requirement to contribute to the Linux kernel, from there the adoption wind was in motion.

As an ex BitKeeper fanboy with a history all the way to RCS, Git was just better.

Re: The creator of Jujutsu has joined ERSC

#242

Post by aseipp »

brilliantee wrote: post #194
anonreplier wrote: post #191

Earlier quoted context omitted.

Who says it's too complex to have multiple implementations? It's under an open source license notably unlike BitKeeper, what's the problem?

Git had a very small initial implementation, while jj is under development for years and is large. If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now? Is it the Google CLA, or are too few people using jj, or is jj too complex, or some mixture of all of the above? The Google CLA is still required as of 2026, which I find strange. https://lwn.net/Articles/958805…

Jujutsu also started out very small, just like Git did. The core concepts aren't too complex. But this is 2026, not 2005 or 2019. Most of the modern Git implementations are extremely large, highly optimized and featureful codebases that are difficult to replicate. Many of Git's performance and structural improvements over the last few years have nontrivial implementations and designs. Jujutsu is also a large, featureful codebase. You can't build a modern Git implementation with all of the highly optimized goodies (multipack indicies, partial clones, etc) and a good UX without a lot of code and work. Or any version control system, frankly. It's just how it is.

- Gitoxide is 80,000+ lines of code.

- Git itself is over 170,000 lines of code.

- Even "Game of Trees" or "got" by the OpenBSD developers, which is a wholly separate project that has its own porcelain, is +120,000 LOC.

- Jujutsu itself is about 100,000 LOC.

- JGit for Java is around 200,000 LOC.

These are all roughly approximate and include things like testing code (but I think that's fair because tests are part of the project). All of these projects started small years ago, and are now large.

> If jj is not too complex to have multiple implementations, why have new implementations not sprung up by now?

"Make multiple implementations" is not, in and of itself, particularly valuable without some underlying justification to do so. It also is not how (AFAIK) any other version control system has ever worked; Git's "identity" as an on disk format is a particular design choice (with pros and cons), so yes you can get multiple tools with varying levels of features that agree on the basic disk format and poke at it. But most projects just don't work this way, much less other VCSs; there also aren't really many "Linux re-implementations" beyond toys because it is easier to just collectively contribute with each other, because Linux is not a "standard" written in stone, but a living and breathing thing.

Re: The creator of Jujutsu has joined ERSC

#243

Post by skydhash »

saghm wrote: post #237
skydhash wrote: post #105

Earlier quoted context omitted.

> I'd argue that the reason a lot of developers have not learned git in depth is because it's actually kind of terrible from a UX standpoint Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started u…

Can you give me a a terse summary of what "checkout" means that doesn't involve needing to either list or ignore several very different types operations?

I would say “align the worktree (or part of it) to a specific state previously saved in the repository.”

The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

Re: The creator of Jujutsu has joined ERSC

#244

Post by dullcrisp »

umvi wrote: post #239
dullcrisp wrote: post #198

Earlier quoted context omitted.

It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.

> I don’t like to think about how I’d do that with git. git cherry-pick + git rebase -i (to swap commit order)? ?

Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah.

But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.

Re: The creator of Jujutsu has joined ERSC

#245

Post by aseipp »

xyzzy_plugh wrote: post #211
steveklabnik wrote: post #91

Earlier quoted context omitted.

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

How is it under its own org, but changing the CLA is up to Google? Google must therefore administer the separate org? I get why you may want to color this as non-Google-owned but it seems to very much still be Google-owned.

Because Martin was the lead maintainer and original author and worked at Google for over a decade until like a month ago, and so as a project it fell under their typical standards in the Google OSPO department and had a CLA applied. When it moved orgs, they had to own the org too, so they could keep CLA robot in. That's basically it. It's just a really successful project that has grown far beyond one company or person.

In theory there is now nothing stopping us (the community/project leaders) from just... Moving the repo somewhere else. We could do that. It would be a pretty sudden alienation of other Google contributors though and probably piss off their legal department -- 99% of them just submit regular fixes like any user, because they are ordinary users of JJ. They just happen to work at Google. It would just be stirring up shit for nothing. It isn't an unthinkable outcome, but it isn't one we're just going to "do" for no reason or because it would make people posting on forums happier.

Realistically a non-ownership-assigning CLA on a non-copyleft Apache 2.0 project like in this case doesn't actually mean anything or confer any power. It's all just paperwork that serves as a legal ass covering mechanism because big companies use lawyers. It's like checking the "Yes I am over 18 years old" box on a website. I say this as someone who hates the stupid CLA bot and am a contributor.

As far as actual leadership goes Google does not "own" anything in that regard, nor the day to day work, nor can it really force any of the community to do anything. There's 1 maintainer from Google out of 9 total and +95% of major contributions don't come from Googlers, ERSC, or even any particular company. They don't contribute most of the code, they don't lead most of the community, they are vastly dwarfed by the community in total size, contribution count, etc. What "ownership" or leverage do they have beyond a Github org in this setup? It's annoying but it isn't the same thing as being able to exercise meaningful levers of power, in my experience, and so most of us are just fine with it. Even if there was some stupid bullshit like a disagreement over implied trademark rights, the community could just rename and move on and Google would have nothing. That is where the real power lies.

Re: The creator of Jujutsu has joined ERSC

#246

Post by yencabulator »

VorpalWay wrote: post #115
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…

How is this undo different than Git's reflog? Genuinely curious, while I have heard of jj I haven't yet tried it (I read it couldn't handle git submodules, which would have made it dead in the water for my dayjob, that seems to still be the case).

Git reflog is a per-ref log of its previous values. JJ operation log is a whole-repo atomic journal of changes. It's much more powerful. You can e.g. undo a change deep in history that already had multiple descendant branches (that jj rebased for you).

Since jj snapshots the commit you're editing a lot, you can often even jj undo an accidental edit to a just-created file that in git would have still been uncommitted.

Re: The creator of Jujutsu has joined ERSC

#247

Post by dullcrisp »

1718627440 wrote: post #227
dullcrisp wrote: post #198

Earlier quoted context omitted.

It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.

> I don’t like to think about how I’d do that with git. git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~ Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.

I guess you could say it’s a skill issue.

Re: The creator of Jujutsu has joined ERSC

#248

Post by saghm »

steveklabnik wrote: post #110
saghm wrote: post #92

Earlier quoted context omitted.

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.

While this is true, we do care about performance tremendously, and the animation not having good performance cuts against that, so I think it's a very fair criticism. Paying attention to details matters.

That's reasonable. I mostly just found the framing to be unfair rather than the criticism itself; it feels kind of disingenuous to try to draw a connection between performance of git and performance of a webpage IMO

Re: The creator of Jujutsu has joined ERSC

#249

Post by dullcrisp »

jrimbault wrote: post #206
dullcrisp wrote: post #162

Earlier quoted context omitted.

I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.

What if I _want_ a staging area?

Then you’ll probably appreciate being able to manipulate it the same way as any other change, but they could do a better job of marketing it that way.
Post reply on HN