Live data from Hacker News

I see a future in jj

steveklabnik.com

71–80 of 336 posts

Re: I see a future in jj

#71
post #70

> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing,…

The intention with this is to also deprecate the Perforce fork, in my understanding.

But yeah, it's been a lot. Frankly even harder to keep track of from the outside!

Re: I see a future in jj

#72
One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.

Re: I see a future in jj

#73
post #18

Earlier quoted context omitted.

So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git.…

As someone who loves git, has always thought the criticisms about its interface were overstated... but also feels like it maybe has too many incoherent ways of doing things, this is the best sales pitch I could've asked for (and I came to the comments to ask for a sales pitch). Thanks - I'll try jj out the next time I start a hobby project.

Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.

It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.

0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo

1: https://jj-vcs.github.io/jj/latest/operation-log/

Re: I see a future in jj

#74
post #4

Since JJ has technically git compat, I think there's 2 things needed for it to take off 1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs

> LLM knowledge

Give it time. Once JJ resources enter the dragnet of future model datasets, LLMs will get better at regurgitating it.

Re: I see a future in jj

#75
post #4

Since JJ has technically git compat, I think there's 2 things needed for it to take off 1. A good vscode extension (there's two so-so ones that I'm not sure are being updated) 2. LLM knowledge. I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first. When I reminded it it was a vcs it hallucinated half the commands. I ended up figuring it out myself from the docs

> I ask gpt-5 about doing something in jj the other day, it didn't even recognize it at first.

Using VC commands an LLM generates for you sounds like a pretty terrible idea anyway. What if they delete your data? Why not spend 5 minutes searching for information written by a human?

Re: I see a future in jj

#76

[flagged]

I was thinking, it'll probably catch on like Omarchy did, except it's written in Rust, so... little chance of it being milkshake-ducked.

But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it.

Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billion dollars making that easy.

Re: I see a future in jj

#77

Earlier quoted context omitted.

> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact. Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’…

> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular. The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is…

Changesets, the op log, first class conflicts, no staging area.

JJ might produce commits that can be stored in Git, but the affordances are different. If Git wants to adopt them, it becomes no longer Git.

On the other hand, I'm happily using JJ while everyone I collaborate with is using Git. JJ doesn't need to "win" to be useful, it just needs to be useful enough that the people who maintain it continue to maintain it.

Re: I see a future in jj

#78
post #76

[flagged]

I was thinking, it'll probably catch on like Omarchy did, except it's written in Rust, so... little chance of it being milkshake-ducked. But as we say on Hackernews, there are two kinds of people with respect to jj: those who love it, and those who haven't tried it. Doing the same thing, but with better usability, is immensely valuable. Remember, Hackernews thought Dropbox was "just" ssh+rsync, but they made a billio…

I’ve tried it. I don’t love it or hate it. It’s more of a “meh”. I can see how it’d be nice if I was disciplined about my commit history, but I tend to be fine with chunky, clunky git. I don’t spend as much time curating perfect commit history as jj fans seem to.

Re: I see a future in jj

#80

I think the real news is that some people have started to build what might become something like a "jjhub" . https://ersc.io/

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)

What I would love:

- Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation

Post reply on HN