Hacker News Reader

> why would the contributors to jj not just try to make git better by addressing these weaknesses?

Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.

View on HN

This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.

I thought it was simply a response to git5/git-multi getting deprecated once fig became popular.

I'm a bit surprised then, that's one of the things that has kept me from trying it as it feels weird to not have that much control over what gets into the commit. Using magit doesn't help as it's just way too good once you get used to it.

Reply on news.ycombinator.com