Live data from Hacker News

I see a future in jj

steveklabnik.com

101–110 of 336 posts

Re: I see a future in jj

#101
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…

I personally feel quite capable at git and am not looking for another flow or tool.

But. I think it's incredibly useful for organizations to have patterns for how they use git. There can be huge variance! And there's so many people who don't feel comfortable doing interactive rebases (of their feature branches), or other serious monkeying with history.

(I also think jj's flows are incredibly good about avoiding accidental loss of work in a way that git can be extremely dangerous at.)

I think there's a ton of value to having more of a pattern than the free-form jamming that git gives us. The real value I see in jj is that it's more than the toolbox of things git gives one: it's something more learnable, teachable, and directed than git. And it seems to do it pretty well, with style, and less monkey business. I'm still super greenhorn at jj, and honestly lacking the need for it, but I'm excited to see it come along. Especially since it is compatible with so many other VCS.

Re: I see a future in jj

#103
Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

Re: I see a future in jj

#104

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

Right now, nothing special. But this is very much an area that's known about and something may happen in this area, we'll see.

Re: I see a future in jj

#105
post #25

Earlier quoted context omitted.

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.

Both Claude and Gemini can be integrated reasonably by informing them how to use JJ commands or even through MCP

Re: I see a future in jj

#106
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…

> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git.

When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden.

That's definitely something that could be better for me. (That said, there are other projects making it better too.)

Re: I see a future in jj

#107

Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).

Perforce’s binary support is basically equivalent to Git LFS, it does the same thing.

What does Perforce binary support have that Git LFS doesn’t?

AFAIK, the base issue that Perforce is already in use and it has enterprise support.

Re: I see a future in jj

#108
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?

I'm not running them blindly and I do always ask the llm to explain the command since the end goal is not to have the llm do the work but rather for me to learn jj.

+ any good tool will not let you run destructive commands without confirmation unless it's with some force flag and I have enough computer knowledge to not use force flags blindly.

+ "information written by a human" can be unreliable too.

Re: I see a future in jj

#109
post #106

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…

> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git. When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden. That's definitely something that could be better for me. (That said, there are other projects making it bette…

Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.

Re: I see a future in jj

#110
post #106

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…

> Having said that, I don't know why a "jjhub" is needed. Github seems fine. jj's just a UI for git. When you make a change to a pr in response to review feedback, do you just jj edit it in, and end up with a force push on GitHub? After which the review comment might get detached from the code or even hidden. That's definitely something that could be better for me. (That said, there are other projects making it bette…

Without knowing much about jj, isn't this more of a problem in how the GitHub/GitLab/Forgejo Pull Request system works rather than a jj problem?

Patch-based workflows in general (where you heavily use git rebase -i to curate a smaller set of "perfect" commits for anything you'd PR, rather than just piling new commits onto every PR) don't work well with the GitHub approach, which heavily favors merging stuff through the web interface (making merge or squash commits along the way).

You can make it work of course, but GitHub tends to behave in weird ways when it comes to how it's interface works with patch-based workflows. Perhaps a better estimate would be to see how it compares to a forge like Phorge or Sourcehut.

Post reply on HN