Live data from Hacker News

I see a future in jj

steveklabnik.com

61–70 of 336 posts

Re: I see a future in jj

#61

[flagged]

> There are no substantial technical or usability reasons to switch to JJ from Git [...]. This is a neutral impersonal opinion that is virtually a fact. I respect your opinion, but I don't think it's a fact and I couldn't disagree any further with it. I wrote a whole testimonial about why I love jj (first one there): https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us... > it's impractical for most working p…

> I respect your opinion

Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.

Re: I see a future in jj

#62

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 :)

Re: I see a future in jj

#63
post #25

Earlier quoted context omitted.

I do think that GUI stuff is important, there's a lot of folks who have said "not interested unless there's a magit equivalent" which I totally understand. I'm not a big GUI person for VCS myself, so I don't feel the same pain. For LLMs, yeah this is hard for any new project. I use Claude Code, and it does a decent job with jj, it only tries to do git stuff sometimes. I haven't asked ChatGPT about it though, I'll hav…

Since they guy behind it works at Google, I wonder if gemini is better at it.

Doubt the gemini team handpicks training material based on wether the author works at google or not. Doubt they handpick it at all.

Re: I see a future in jj

#64
I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review?

I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and plans you have at ERSC.

But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in. The distributed nature of git somehow got lost with PRs or MRs in GitHub & Co.

Re: I see a future in jj

#65
post #6

At the risk of being unreasonably negative, stuff like this just makes me feel... tired. Git is... fine. I'm sure it doesn't solve every problem for everyone, and oh boy does it still have many rough edges, but it works and (as the article points out), git has won and is widely adopted. I've extensively used CVS and Subversion in the past. I touched Mercurial and Bazaar when I ran into a project that used it. I remem…

jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all…

I have a question and you might have an idea about this:

I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do.

I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything manually.

Do I understand correctly that jj does it automatically?

Re: I see a future in jj

#66
post #64

I tried Jujutsu in the last day and was going through your tutorial. I really liked the experience and can see some potential. I also got the feeling that there is a missing puzzle piece. For example, do I get any benefit from the change id if I push to GitHub for PR review? I guess you benefit from some of the good parts only with the Google internal Piper backend, at the moment. So I’m curious about the ideas and p…

Glad to hear you enjoyed it :)

> do I get any benefit from the change id if I push to GitHub for PR review?

As of right now? Not really. The details are more complicated, but basically, if your project doesn't like the behavior of github when it comes to comments + editing commits, and wants you to tack on new commits instead, we can't change that behavior. However, https://github.com/LucioFranco/jj-spr can, in some situations, give you some of this experience. If your project is okay with editing commits, then it can help you locally, sure.

However. In an interesting turn of developments, GitHub's new SVP just tweeted that he's likes jj and is interested in adding stacked diffs to github. I don't know how this squares with their "no new features for 18 months" thing, but we'll see!

> But what I’m also really yearning for is having a distributed asynchronous/offline-first code review flow built right in.

It's not code review, it's issue tracking, but I've been using https://github.com/steveyegge/beads this week, and I think it might be the first "put your issues in your repo" system I actually enjoy. It says it's built for AI stuff, but like, you don't have to use AI with it.

Re: I see a future in jj

#67

Earlier quoted context omitted.

jj is actually so good though. People don't need to know you're using it, which is why it's nice. A problem I run into when working with other people is that code reviews take forever and I need to build on top of them. Code gets merged while it's being reviewed, and it becomes a burden to keep rebasing your stack of PRs. It's also difficult to do things like designing each PR against the main branch, but testing all…

I have a question and you might have an idea about this: I have a workflow where I have my main and a bunch of branches that are children of other branches. So: main, branch_a, branch_a_1, branch_a_2, branch_a_1_x, etc. Probably not a good workflow, but that's what I do. I keep editing old commits in my branches to have clean, atomic commits, which fucks up my branch structure and I need to cascade-rebase everything…

That's correct, it will do the cascade rebase of everything automatically.

Re: I see a future in jj

#68

After reading the article, the technical merits of `jj` are completely unclear.

Yes, that was not the goal of the post. There's some comments about this in this thread though, here's the first one of mine: https://news.ycombinator.com/item?id=45673808

That URL https://news.ycombinator.com/user?id=steveklabnik is a link to your user profile.

Re: I see a future in jj

#69
post #68

Earlier quoted context omitted.

Yes, that was not the goal of the post. There's some comments about this in this thread though, here's the first one of mine: https://news.ycombinator.com/item?id=45673808

That URL https://news.ycombinator.com/user?id=steveklabnik is a link to your user profile.

Whoops, managed to fix it. Thank you!

Re: I see a future in jj

#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, all in 7-ish years?

Post reply on HN