Hacker News Reader

Comment by mpalmer | Hacker News Reader

The point of jj is to improve on the git interface. It's kind of weird to imply that jj's purpose is a drawback. I don't want git to stay git. Nor do I want SAAS solving stacked PRs for me, "free option" or not.

jj is explicitly not for teams - there's no way to share jj-proprietary stuff between checkouts of a repo, because it's a frontend for interacting with a git repo.

View on HN

Graphite also improves on the interface if you want that. I personally have no issues with git anymore having spent nearly two decades working with it.

Ehhh, when I explain jj to people I like to say that it is "a tool to edit git repos", and that "the repo is still a git repo" because people have so many misconceptions of how jj works. When they see how different jj's interface is from git, they think it's a whole new VCS and are worried that it will break compatibility with other git tools.

That said, I only do this to avoid overwhelming beginners, when actually learning/using jj it is definitely more useful to think of it as a different VCS.

Telling people it's a tool to edit git repos makes it sound hackier than it is; not surprising they're nervous it'll break something.

Just tell them git makes mistakes easy, and jj makes them difficult.

I've tried that but it isn't very effective because usually if they are not a git wizard, they are already using some sort of git interface or GUI that prevents them from making catastrophic mistakes. So they don't see the appeal in relearning all their git knowledge and terminology.

Hence why I initially try to sell it as an addition to their toolbox, instead of as a replacement for their entire workflow.

I agree with you both.

Jj makes mistakes hard, but also makes it easy to just focus on your code and easily sort out anything git-related later as an after-thought.

Reply on news.ycombinator.com