Hacker News Reader

Comment by yuppiepuppie | Hacker News Reader

I get what you are saying about the nicer workflows for those cases.

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

I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined.

Yes, I know that some code bases are too far gone for major enhancements…

View on HN

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

Because the git workflow causes a lot of the difficulty and fixing it involves making a new concept: mutable changesets with a unique id which are built on top of immutable commits.

jj isn’t just some bugfixes or a few porcelain improvements, it deeply changes the way you approach things. And there’s a pretty decent amount of unlearning of subtly-broken concepts you need to do.

None of that could ever make its way into git.

In some sense they already are making git better since that’s the data format that the tool supports.

Also, some of the UI improvements or even protocol improvements might make it into git eventually.

I’m skeptical about it being worthwhile to switch to a new backend. Maybe it would work if it’s just local, but a lot of IDE plugins and other tools would need to be written, and git has lots of inertia.

> 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.

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.

Think of it this way: they are trying to make git better by addressing fundamental weaknesses in git, but some of those weaknesses require a fundamentally different UI paradigm and as such aren’t practical to upstream, hence a new project.

> I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined.

You would have thought? Plugins? Git doesn’t have plugins to my knowledge. Hooks are not plugins for security reasons. Meaning you can’t distribute hooks, have people install them and call it an extension.

Then, assuming that they could just make Git better. Are they interested in supporting all of Git plus their new work? Why would they be?

If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible

Reply on news.ycombinator.com