Most active commenters
  • steveklabnik(7)

←back to thread

I see a future in jj

(steveklabnik.com)
295 points steveklabnik | 25 comments | | HN request time: 0.342s | source | bottom
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 #
1. 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 #
2. jimbokun ◴[] No.45673620[source]
One thing not mentioned in the article: what advantages does jj offer over plain git?
replies(1): >>45673808 #
3. kelnos ◴[] No.45673767[source]
Sure, definitely, sorry for being a bit off-topic, clearly this was about you and your plans and not intended to be about jj itself.

Having said what I said, I do find new tools to be interesting, and I do hope jj ends up being successful. I'm always happy to be surprised by something that fixes problems that I didn't consciously know I had, or that adds new features or work modes that make my life easier in ways that never would have occurred to me in the first place. I was a pretty early git adopter, and it works great for me, but I'm sure a decent chunk of that is because I understand how it works under the hood, even if it often doesn't present a great UX.

And even if jj doesn't eventually surpass git's popularity, it's great to have other options, and avoid monocultures.

4. 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 #
5. jimbokun ◴[] No.45673846{3}[source]
So better UX while keeping git's solid internals?

Makes sense. Developers I know have been wanting that.

replies(2): >>45673923 #>>45674368 #
6. wk_end ◴[] No.45673901{3}[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 #
7. steveklabnik ◴[] No.45673923{4}[source]
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.
replies(1): >>45674448 #
8. steveklabnik ◴[] No.45674078{4}[source]
You're welcome, and feel free to let me know how it goes. There is an adjustment period, for sure, and (in another eerie parallel to Rust) some folks try it, bounce off, and try again later, and it sticks then.

The auto-commit behavior was one of my biggest concerns when starting, but it turns out that when combined with other things, I'm a huge fan now, for example.

9. nonethewiser ◴[] No.45674170{3}[source]
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."

replies(4): >>45674440 #>>45674578 #>>45674608 #>>45678954 #
10. SoftTalker ◴[] No.45674368{4}[source]
Not the only project that's working on that.

https://www.gameoftrees.org/

11. steveklabnik ◴[] No.45674440{4}[source]
Could you spell out slightly more what you mean? I'm not 100% sure what "get" means.
replies(1): >>45674700 #
12. warwren ◴[] No.45674448{5}[source]
I can't hear Piper backend without thinking about Pied Piper
13. baq ◴[] No.45674578{4}[source]
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.
14. mckn1ght ◴[] No.45674608{4}[source]
Right, “parent branch” implies a tree structure, but git is a DAG.

You might have a specific workflow such that you can actually answer your question, but it won’t generally apply to all repos.

Since a branch is really just a label for a specific commit, which may be at the end of a chain of successive parent commits, a branch isn’t really a first class structure, but a derived one.

You can get the fork point of a branch, which is a common ancestor commit shared by another branch, but that fork point is a commit and may not have a branch label. That commit can have any number of other branches going off of it: how would you decide which one is the parent vs just another sibling?

My assumption after looking at jj is that it is not as complicated as git yet. Give it time. It’s also not even as simple as git for many tasks, based on their own docs: https://jj-vcs.github.io/jj/latest/git-command-table/

15. petre ◴[] No.45674695{3}[source]
Git's CLI is awful compared to fossil or even mercurial. Jj seems like an improvement over git, but it lacks a web UI like fossil has. It's very useful. Basically like a self contained github lite, only without the needless complexity, the enterprise bs, the annoying login process, tokens, passkeys, brain damaged permissions system etc.
16. 1718627440 ◴[] No.45674700{5}[source]
I think they mean what other branch some branch was originally branched off from.
17. lowboy ◴[] No.45675132{4}[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 #
18. socalgal2 ◴[] No.45675737{5}[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 #
19. mkeeter ◴[] No.45675972{6}[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)

20. steveklabnik ◴[] No.45676015{6}[source]
I’m not sure if it’s a typo, but you don’t need to edit and then new, you can just new. It’s a good habit to get into as a replacement for checking something out.

I’m not sure what happened in your conflict situation either, that does sound frustrating. EDIT: Oh, I wonder if it was this: https://jj-vcs.github.io/jj/latest/technical/concurrency/ specifically, that I bet the repo was being modified concurrently, and so you ended up with a divergent change.

21. lowboy ◴[] No.45676061{6}[source]
> You can't do jj this, jj that, jj other, jj undo, jj undo, jj undo AFIACT

You can as of v0.33.0[0]. Previous behaviour was that `jj undo; jj undo` would leave you where you started (it undid the undo).

> 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'm not 100% clear on what you mean here, but a few things that might help:

1. In jj you don't "checkout" a branch, you edit a specific commit. That commit might be pointed to by a bookmark but it doesn't have to be. A jj bookmark is roughly equivalent to what git calls a branch. Note that a git branch, and a jj bookmark are just pointers to a commit, as illustrated here[1]).

2. If you want to resume work on a branch/bookmark instead of `git checkout BRANCHNAME` you'd do `jj new BRANCHNAME` which puts a new commit on top of the commit and sets it as a working copy.

3. Bookmarks don't auto advance like they do in git. So adding new commits on top of a "branch" will leave the bookmark where it is until you `jj bookmark set/move` it. So you could squash commits down into the "foo" bookmark, but you could also move "foo" to point to subsequent commits.

4. Not sure what you mean by edits being invisible, but if it's seeing a diff from main to the tip of your branch (with a change id of ex. XYZ) it would be `jj diff -f main -t XYZ`.

0: https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md#0330---2...

1: https://social.jvns.ca/@b0rk/111709462585184810

22. zZorgz ◴[] No.45677921{3}[source]
Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.

If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)

That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).

replies(1): >>45677946 #
23. steveklabnik ◴[] No.45677946{4}[source]
Yeah, in that case you may want to configure bookmarks to auto update for sure :)
replies(1): >>45678147 #
24. zZorgz ◴[] No.45678147{5}[source]
Is there a way to do that today?

For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).

It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.

25. KingMob ◴[] No.45678954{4}[source]
That's even less how jj works, unfortunately for this use case, because jj doesn't require branches to be named.

You could probably attach metadata to commits indicating the branch name at time of creation, but there's probably a lot of weird edge cases to handle.