←back to thread

I see a future in jj

(steveklabnik.com)
291 points steveklabnik | 1 comments | | HN request time: 0s | source
Show context
kelnos ◴[] No.45673281[source]
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 remember in the CVS days, SVN was exciting to me, because CVS was such a pain to use, in almost every way. In the SVN days, git was exciting to me, because SVN still had quite a few pain points that poked me during daily use. Again, yes, git had and has rough edges, but nothing that would make me excited about a new VCS, I don't think.

Maybe I'm just getting old, and new tools don't excite me as much anymore. Learning a new tool means spending time doing something that isn't actually building, so my eventual use of the new tool needs to save me enough time (or at least frustration, messily converted into time units) to balance that out. And I need to factor in the risk that the new tool won't actually work out for me, or that it won't end up being adopted enough to matter. So I think I'll wait on jj, and see what happens. If it ends up becoming a Big Deal, I'll learn it.

replies(10): >>45673426 #>>45673659 #>>45673916 #>>45673995 #>>45674049 #>>45674219 #>>45674653 #>>45674662 #>>45675434 #>>45676064 #
steveklabnik ◴[] No.45673426[source]
I think being conservative about tool use is totally fine! I'm actually pretty conservative about most of the tools that I use.

The goal of this post wasn't really to convince anyone on why they may want to give jj a shot, more of just a post about how I think about technologies I may want to spend my limited time on this planet working on, and announce that I'm making a move.

I don't think that you're being unreasonably negative. I think it's crucial for technologies to understand that your position is basically the default one, and that you need to offer a real compelling reason to choose a new tool. For some people, jj has enough of that already to bother with choosing, but I think the real power is in things that aren't widely available yet. Hence the need to go build some stuff. It's early days! Not even 1.0 yet. It's very natural that most people do not care at this stage.

replies(2): >>45673620 #>>45673767 #
jimbokun ◴[] No.45673620[source]
One thing not mentioned in the article: what advantages does jj offer over plain git?
replies(1): >>45673808 #
steveklabnik ◴[] No.45673808[source]
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. I was never the kind of person who thought its CLI was bad. But then, when I found jj, I realized why people thought that.

replies(5): >>45673846 #>>45673901 #>>45674170 #>>45674695 #>>45677921 #
wk_end ◴[] No.45673901[source]
As someone who loves git, has always thought the criticisms about its interface were overstated... but also feels like it maybe has too many incoherent ways of doing things, this is the best sales pitch I could've asked for (and I came to the comments to ask for a sales pitch). Thanks - I'll try jj out the next time I start a hobby project.
replies(2): >>45674078 #>>45675132 #
lowboy ◴[] No.45675132[source]
Another good sales pitch is `jj undo`[0]. It puts the repo back to previous state, regardless of what the mutative operation was. It's a powerful and simple safety net that unlocks experimentation.

It does this by adding an new operation on top of the operation log[1], so you don't lose repository states by moving up + down the op log. There's a corresponding `jj redo` as well.

0: https://jj-vcs.github.io/jj/latest/cli-reference/#jj-undo

1: https://jj-vcs.github.io/jj/latest/operation-log/

replies(1): >>45675737 #
socalgal2 ◴[] No.45675737[source]
jj undo is great but it's a one time thing. You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT. You have to look into the op log and jj op restore for that. It's nice you can get back to where you were though.

The biggest issue for me is it requires active change management (or feels like it). In git I do `git checkout foo` then I start editing. If I want to see what may changes are since foo then `git diff` tells me. With jj though, `jj edit foo` is the to git, state of the repo ALL changes to foo. So any new edits are invisible. So, instead of `jj edit` I have to do `jj edit` `jj new`, then later squash those into foo

I know there are similar cases in git but I guess I'm just used to git so I wasn't using those cases.

that said, I'm mostly enjoying jj. Though quite often i get a conflict I don't understand. Today I got 2 and it told me choose A or B. I did `jj diff -r A -r B` and it said no diffs. If no diffs aren't there no conflicts? I'm sure someone gets it but it was annoying to just have to pick one to abandon

replies(3): >>45675972 #>>45676015 #>>45676061 #
1. mkeeter ◴[] No.45675972[source]
> jj undo is great but it's a one time thing.

For what it's worth, this changed in v0.33.0:

> jj undo is now sequential: invoking it multiple times in sequence repeatedly undoes actions in the operation log.

(release notes: https://github.com/jj-vcs/jj/releases/tag/v0.33.0)