Top
Best
New

Posted by tigerlily 3 days ago

jj – the CLI for Jujutsu(steveklabnik.github.io)
542 points | 493 commentspage 6
jancsika 2 days ago||
I was going to write a big long comment, but honestly it boils down to this:

Whatever git's practical benefits over SVN and CVS back in the day (and I can go into the weeds as a user if someone wants that), git was the DVCS that took over from the centralized VCS's of that era.

There is nothing in jj, pijul, or Bram Cohen's thing that is anywhere near as dramatic a quality of life improvement as going from VCS to any DVCS. And dramatic improvement is what is needed to unseat git as the standard DVCS.

I mean, if you're not doing something so important[1] that it adds a letter to the acronym, it's probably not the next new thing in version control.

1: I originally wrote the word "novel" here. But it has to be big-- something like guaranteeing supply chain integrity. (No clue if a DVCS can even do that, but that's the level of capability that's needed for people to even consider switching from git to something else.)

rstuart4133 2 days ago|
There is some truth to that, but to give a different perspective ...

A long, long time ago, back when VCS's were novel enough to be of academic interest, I read numerous papers describing what these VCS's could be. They talked in terms of change sets, and applying them like a calculus to source code. In the meantime those of us writing code people actually used were using sccs and rcs, or if you were really unlucky Visual SourceSafe. To us in the trenches those academics were dreamers in ivory towers.

With the passage of time we got new VCS that gradually knocked the rough edges off thoase early ones. svn gave us atomic commits, hg gave us a distributed VCS, git gave us that plus speed. But none came close to realising the dreams of those early academics. It seemed like it was an impossible dream. But then along came jj ... and those dreams were realised.

tucnak 3 days ago||
16 year-old me would have been very impressed by this!
auggierose 3 days ago|
Is that a compliment, or the opposite?
tucnak 3 days ago||
A bit of both. I guess it's nice, but nothing I actually care about.
xtracto 3 days ago||
I had a similar thought: there surely are lots of young folks who will be all excited with this (I was back in the CVS/SVN days when git appeared).

But nowadays I'm extremely lazy to attempt to learn this new thing. Git works, I kind of know it and I understand its flow.

cestith 3 days ago|||
We still have some repos in Subversion and most things in git. It’s still exciting for every repo we get migrated out of svn. That’s a high bar to cross if we’re talking further improvements compared to git though.
steveklabnik 2 days ago||||
I was 38 or 39 when I found jj.
hacker161 2 days ago||
See? You weren’t even over 50! Young whippersnappers…
nithril 3 days ago|||
Same here, I’m not experiencing so much friction to justify looking for an alternative
bikelang 2 days ago||
Reading threads like this and the GitHub stacked PRs just makes me feel like an alien. Am I the only one that thinks that commits are a pointless unit of change?

To me - the PR is the product of output I care about. The discussion in the review is infinitely more important than a description of a single change in a whole series of changes. At no point are we going to ship a partial piece of my work - we’re going to ship the result of the PR once accepted.

I just squash merge everything now. When I do git archeology - I get a nice link to the PR and I can see the entire set of changes it introduced with the full context. A commit - at best - lets me undo some change while I’m actively developing. But even then it’s often easier to just change the code back and commit that.

steveklabnik 2 days ago||
You're not an alien: this is the workflow that GitHub encourages.

It's just that not every tool is GitHub. Other systems, like Gerrit, don't use the PR as the unit of change: they use the commit itself. And you do regularly ship individual commits. Instead of squashing at the end, you squash during development.

bikelang 2 days ago||
Thanks for explaining that. Having a bit of a (dim) lightbulb moment now. I’ve never used Gerrit - just GitHub and GitLab and Forgejo. So I assumed the PR/MR model was more or less universal. But if smaller development commits are being squashed into the shippable/reviewable unit - then the focus on commits makes a lot more sense.
steveklabnik 2 days ago||
You're welcome! It is one of those "do fish realize they're wet" kind of things, tools can shape our perception so strongly that you don't even realize that they're doing it!
rs545837 2 days ago||
You could agree that the PR is the meaningful unit for shipping, but push back gently that for agents working in parallel, the commit/changeset level matters more than it used to because agents don't coordinate the way humans do. Multiple agents touching the same repo need finer-grained units of change than "the whole PR."
bikelang 2 days ago||
Could you elaborate a bit more on this? Curious what your workflow looks like. Is this multiple agents running on the same feature/refactor/whatever unit of work? For concurrent but divergent work I just use a git worktree per feature. And I think I only ever have a single agent (with whatever subagents it spins up) per unit of work.
rs545837 2 days ago||
Think two agents working on the same codebase at the same time. Agent A is refactoring the auth module, Agent B is adding a new API endpoint that imports from auth. Separate worktrees, separate branches, but they're touching overlapping code.

ingle agent per feature works great today. But as agents get faster and cheaper, the bottleneck shifts to, how many agents can work on one repo simultaneously without stepping on each other.

zhaoyongjie 2 days ago||
To be honest, JJ is dick in Chinese, literally.
verdverm 2 days ago|
https://chinese.stackexchange.com/questions/31646/is-jj-slan...
scotty79 3 days ago||
Does jj have partial clones of remote repo?
steveklabnik 2 days ago|
jj does not have partial clones, but it does have sparse checkouts.
scotty79 2 days ago||
Thank you for the info.

Sparse checkouts from remote repo directly or do I need to clone it in whole locally and only then can do a sparse checkouts into some work directory?

steveklabnik 2 days ago||
I'm 99% sure it's "clone the whole locally and then sparse checkout from there".
palata 3 days ago||
I tried jj for a few months. It was fun to learn a new thing, but I haven't had a single case of "wow, this would have been a pain with git". Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed".

So it felt like the XKCD on "standards": I now have one versioning system, if I learn jj I will have two. What for?

Don't get me wrong: it's nice that jj exists and some people seem to love it. But I don't see a need for myself. Just like people seem to love Meson, but the consequence for me is that instead of dealing with CMake and Autotools, I now have to deal with CMake, Autotools and Meson.

EDIT: no need to downvote me: I tried jj and it is nice. I am just saying that from my point of view, it is not worth switching for me. I am not saying that you should not switch, though you probably should not try to force me to switch, that's all.

naasking 3 days ago||
> Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed".

The core issues are: how long did it take you to get there, how many lucky decisions did you have to make to not run into git footguns, and how many other people accidentally made different choices and so have very different experiences from you?

palata 2 days ago||
What you're saying is that other people may find jj easier for them, right?

I am fine with that. I am just saying that the "you should use jj, you will finally stop shooting yourself in the foot regularly" doesn't work so well for me, because I don't remember shooting myself in the foot with git.

BeetleB 2 days ago||
For me, it was kind of the same. I used jj. Really liked it, but did not find it all that much better than git.

Then, for various reasons, I switched back to git.

By day 2, I was missing jj.

Stuff like "jj undo" really is nice.

newsoftheday 2 days ago||
[dead]
carverauto 2 days ago||
am a big fan, just started using it a few days ago
jtrueb 2 days ago||
Call me crazy, but jj is more confusing than git.
dhruv3006 3 days ago|
this looks pretty interesting.
More comments...