Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.
jj has almost 30,000 stars on github. You might not be looking for a different git ux, but plenty of people are!
jj – the CLI for Jujutsu
161–170 of 517 posts
Re: jj – the CLI for Jujutsu
#162"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
Actually it is a anti-demo, because while software allows you to do it, I don't think many software engineers can work on this.
Re: jj – the CLI for Jujutsu
#163Earlier quoted context omitted.
think of jj like, I want to build xyz, ``` jj desc -m "feat: x y & z" ``` do the work. ``` jj split ``` Split up the parts and files that you want to be separate and name them. This will also allow you to rename stuff. ``` jj bookmark create worklabel-1 -r rev1 jj bookmark create worklabel-2 -r rev2 # Push both commits # since we just split them they are likely not inter-dependent # so you can rebase them both to bas…
I am dumb. why is that better than a git branch or a git worktree ?
If you're already super comfortable in git, it's not. I'm saying this as someone who recently converted from git to jj and never wants to go back.
You also don't have to follow what the GP said. I never say `jj describe` before writing code. I write the code then just say `jj commit -m "Foo stuff"`, just like I would in git.
The bigger difference I've noticed is:
1. Switching between changesets just feels more natural than git ever did. If I just run `jj` it shows me my tree of commits (think of it like showing you git's branches + their commits), and if I want to edit the code in one of them I just say `jj edit xyz`, or if I want to create a new commit on top of another one and branch it off in a new direction, I just say `jj new xyz`. It took a little bit for my brain to "get" jj and how it works because I was so used to git's branches, but I'm really enjoying the mental model.
2. `jj undo`. This alone is enough to convert me. I screwed something up when trying to sync something and had a bunch of conflicts I really didn't want to resolve and I knew could have been avoided if I did things differently, but my screwup was several operations ago! So I ran `jj undo`. And ran it again. And again. And again. And then I was back to my clean state several stages ago before I screwed up, despite having made several changes and operations since then. With git? Yeah I could have gotten it fixed and gone back. But every time I've had to do something like that in git, I'm only 25% confident I'm doing it right and I'm not screwing things up further.
3. Rebasing. When I would try to sync git to an upstream GitHub repo that used rebasing for PRs, I would always get merge conflicts. This was because I stack my changes on top of each other, but only merge in one at a time. Resyncing means my PR got a new commit hash, even though none of the code changed, and now git couldn't figure out how to merge this new unknown commit with my tree, even though it was the same commit I had locally, just a different hash. With jj? I never get merge conflicts anymore from that.
Overall the developer experience is just more enjoyable for me. I can't say jj's flow is fundamentally and objectively better than git's flow with branches, but personally and subjectively, I like it better.
Re: jj – the CLI for Jujutsu
#164"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
Guess he was talking about the presentation, not what the tool can achieve. It has no hard proof on the first page, which could easily just be a LinkedIn pitch, but not on hackernews
Re: jj – the CLI for Jujutsu
#165JJ might be good (this article couldn't convey why in the "What is jj and why should I care?" page) but it's not 10x better than git, so it will likely die. Sorry, nothing personal, Mercurial/hg was a little bit better than git and died too. Network effects. What has a change is ast-based version control. You adding a feature to a function that uses a struct I renamed shouldn't be a conflict. Those actions don't conf…
Did you confirm that the network effects are applicable here before posting that?
Re: jj – the CLI for Jujutsu
#166"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
It might count, but it is easy with git as well, what is the feature in jj that makes this easier? Switching branches and pushing changes to remotes is the core feature of git and in my opinion really easy so I'm curious how jj improves on it.
Re: jj – the CLI for Jujutsu
#167So glad to see this on HN, here to support it. JJ is amazing, the hardest hurdle was not the tool but the toolchain and ecosystem when I started ~ 2 years ago. It's grown rapidly and is incredible to see the community grow!
Re: jj – the CLI for Jujutsu
#168> $ cargo install jj-cli@0.23.0 --locked I won't install Rust just to test your software. Make a debian package like everyone else.
Immediately after that line:
> If you're not a Rust developer, please read the documentation to figure out how to install things on your platform
Rather selective reading we have here, don't we?
Re: jj – the CLI for Jujutsu
#169I'm still struggling most with the fact that my day-to-day work involves a git first platform like GitHub. Although jj as a vcs system, it does feel better, working with git through it still feels like a chore, but to be fair I only gave it a day before going back to git. Does anyone have any good resources on how to augment a git flow through the lens of a git hosting platform to work smoothly and still reap the ben…
I'm not sure what the hangup is, TBH. I use `jj` with GitHub and ADO every day, and it works great.
What specific challenges are you running into that make it feel like a chore?
Re: jj – the CLI for Jujutsu
#170Hey folks!
So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it.
Happy to answer any questions!