Live data from Hacker News

I see a future in jj

steveklabnik.com

41–50 of 336 posts

Re: I see a future in jj

#41

[flagged]

> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch.

Not in my experience. jj is easy to pick up and a joy to use. I like git. I deeply appreciate git. But git can feel like snow shoveling sometimes, while in jj things just click into place.

jj is freeing, because things that were a hassle before are now easy, and other things that were impossible are also easy.

I know there's a lot of hype around for a lot of things, and I get grumpy from all of it. Jujutsu is one of the few things that actually deserve the praise being heaped on them.

You may disagree, of course. But I hope that some day, you'll have reason to be happy about this tool, instead of feeling... whatever touched you off like this.

Re: I see a future in jj

#43

Earlier quoted context omitted.

So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git.…

can you directly get the parent branch of a branch in jj? This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."

Could you spell out slightly more what you mean? I'm not 100% sure what "get" means.

Re: I see a future in jj

#44

Earlier quoted context omitted.

So better UX while keeping git's solid internals? Makes sense. Developers I know have been wanting that.

It's technically a bit more than that. JJ is its own VCS, with pluggable backends. Google has a closed-source Piper backend, the git backend is the only real open source backend. But at high level, it's fine to think about it in that way, yeah. I tend to think about it as being more "able to work on git repos" than as a UI.

I can't hear Piper backend without thinking about Pied Piper

Re: I see a future in jj

#45
post #33

I joined the sapling/subversion company this year, but haven’t had the chance to use jj. But given its resemblance I must say sapling has been great. Much more intuitive than git, and I find commit stacks much easier to follow than branches. I do wonder how it will work without the level of support of Meta, since you won’t have the same commit stack review UI (basically a series of pull requests being reviewed at the…

Yeah, sapling and jj are fellow travelers, for sure :)

Re: I see a future in jj

#46

[flagged]

> There are no substantial technical or usability reasons to switch to JJ from Git and it's impractical for most working programmers to switch. This is a neutral impersonal opinion that is virtually a fact. Not a thing in here is true, especially not objectively true. As neutral as you may believe yourself, it might be a good time to step back and reexamine your priors that led you to state so confidently that there’…

> it might be a good time to step back and reexamine your priors that led you to state so confidently that there’s no usability reason to switch in particular.

The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.

Re: I see a future in jj

#47
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 used to think the same way about jj not too long ago. I even wrote a few comments here similar to yours, but since then I’ve changed my mind. For me, the turning point was realizing that jj actually eased some of the frustrations I had with our rebase workflow at work. It took a while for it to click, but now I wouldn’t want to go back

May I ask what is your rebase workflow at work?

In my day to day, its basically "git pull --rebase repo branch", plus some interactive rebate to squash commits, and it's not particularly frustrating, so I'm curious what you're doing that we're not.

Re: I see a future in jj

#49

[flagged]

This comment could have been written when people were pushing to SVN repos on SourceForge when Git was becoming the next big thing, enough for a competitor to founded.

Yet still, the status quo is not Subversion and SourceForge, both of which have been relegated to antiquity, but git and GitHub.

Will something else unseat git and GitHub in the coming years? And will it be Jujutsu or some other innovation on version control?

Who knows, but I see no need to be so dismissive of somebody’s passion in such an arrogant way.

Re: I see a future in jj

#50

Earlier quoted context omitted.

So for me, the most compelling thing about jj is that it is somehow simpler than git, while also being more powerful than git. What I mean by simpler is, there's fewer features, which makes things easier to pick up, because these features fit together in a way that's more coherent than git's. By more powerful, I mean jj lets me regularly do things that are possible, but annoying and/or difficult in git. I loved git.…

can you directly get the parent branch of a branch in jj? This is one thing that I constantly find myself wishing was in git but inevitably resign myself to knowing "thats just not how git works."

I don’t think you ever need to do this, jj tracks changes much better than git, assuming I understand your question. E.g. you can rebase a whole local change dag based on a commit from origin with a single jj rebase -b and it’ll move bookmarks (git branches) correctly.
Post reply on HN