Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

251–260 of 336 posts

Re: I see a future in jj

#251

Post by [deleted] »

jtwaleson wrote: post #245
mpalmer wrote: post #237

Earlier quoted context omitted.

More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Not true. Using jj is a choice made by a single developer. Nothing proprietary escapes from a jj clone of a git repo. Junior devs can use vanilla git if they really want to. All the tooling that works with e.g. repo analysis will need to start supporting git and jj Also not true, unless I misunderstand what…

I see what you mean, and having looked a bit more deeply today, it's clear that jj is very compatible. However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Wind…

[deleted]

Re: I see a future in jj

#252

Post by mpalmer »

jtwaleson wrote: post #245
mpalmer wrote: post #237

Earlier quoted context omitted.

More docs need to be created, junior developers will need to learn both systems (as git is not going anywhere). Not true. Using jj is a choice made by a single developer. Nothing proprietary escapes from a jj clone of a git repo. Junior devs can use vanilla git if they really want to. All the tooling that works with e.g. repo analysis will need to start supporting git and jj Also not true, unless I misunderstand what…

I see what you mean, and having looked a bit more deeply today, it's clear that jj is very compatible. However, my point is that having two ways of doing this within a team is already confusing. What if one person writes a "this is how we work" document on the wiki and mentions some git, and the next person rewrites it to jj? It's extra things to think about. It's like supporting developers from a team with both Wind…

If a team has members who unilaterally rewrite best practice docs to include their preferred technologies, the fault is not with the tech.

Re: I see a future in jj

#253

Post by mpalmer »

jtwaleson wrote: post #209
fsw wrote: post #208

Earlier quoted context omitted.

We had rcs, cvs, svn, and now git. Why would it be the ultimate VCS and not be replaced again by something better?

If a product is 10x better than what's currently available, it will see rapid adoption. There was obviously something about git that made it MUCH better than the precursors and that's why it obliterated everything else. I highly doubt that new tools will be 10x better than git. Maybe 20%?

You should really try it; it's clear you're learning some things about it just from this thread.

Will a product that is 10x better see rapid adoption if people who have not used it still choose to criticize it in the abstract?

Re: I see a future in jj

#254

Post by mpalmer »

CuriouslyC wrote: post #248
jtwaleson wrote: post #173

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that…

Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracki…

I have no idea what problem this is supposed to solve. Where is the V in VCS here? How do you track the provenance/history of changes?

You may not be "forcing" developers to "screw with a graph" (what?) but you are forcing them to screw with macros (we're adding a built-in scripting layer to the VCS?) and these unfamiliar new concepts called atoms and plans.

> A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans)

And it would introduce zero new confusing issues of its own?

> This would also [...] make it easy to swap in and out functionality from the atom database instead of having to hunt through the commit graph and create a patch.

This is a weird use case. Version control systems aren't typically used for storing and swapping around bits of functionality as a first-class, ongoing concern.

Not to mention you still need to figure out how atoms get stitched together. How do you do it without diff-based patches? No superior solution exists, AFAIK.

    tl;dr use workspaces if you're using agents.

Re: I see a future in jj

#255

Post by suralind »

I’ve been adopting jj for my personal projects for 1-2 months and have been very happy with it. One downside is if you move back to edit older revisions, it’s very easy to accidentally append something that was added to .gitignore in the meantime. I suppose it’s a relatively unique problem. Other than that I definitely like it, but my git knowledge accumulated over the years is still much larger than jj.

I’m going to be slowly adopting it for work.

Re: I see a future in jj

#256

Post by cryptonector »

oefrha wrote: post #130

I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For pe…

> Plus I rebase a lot

Exactly, me too. Things like `absorb` I'll take, but I don't want jj's opinionated approach to version control. And not only do I not want it for _me_, but I also don't want it for newbies because hiding too much of the underlying design, design issues, etc., seems counterproductive to me.

Re: I see a future in jj

#257

Post by pm215 »

1718627440 wrote: post #227
pm215 wrote: post #224

Earlier quoted context omitted.

I would love the git index to not be a thing you had to care about unless you deliberately wanted to use that feature, but in my experience this is not the case...it feels to me like an implementation detail that surfaces into the UI more than it ought to.

But that is the thing, it is not exposed as an implementation detail, it is a skipable part of the user model.

I find myself from time to time with stuff in the index (merge conflicts in particular I think can result in this). I never put anything there explicitly. I would love to be able to configure git such that the index didn't exist, but I can't.

Re: I see a future in jj

#258

Post by pm215 »

steveklabnik wrote: post #243
pm215 wrote: post #223

Earlier quoted context omitted.

As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it,…

This sort of flow is very nice in jj, primarily because of the “no index” plus “auto commit” behavior, I’ll regularly go “oh yeah I want to go do that” and I’m about to just go do it and then come back to right where I left off, since my work is already saved.

Yeah, I get the impression jj is good for this, and if I were using raw git then it would be a massive upgrade. Luckily for me stgit already does what I want in this area so I have no strong need to investigate alternatives, but if stgit ever bitrots then jj might be a useful next thing.

Re: I see a future in jj

#259

Post by SAI_Peregrinus »

bagxrvxpepzn wrote: post #46
mirashii wrote: post #36

Earlier quoted context omitted.

> 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…

The substantial technical difference is that the UI (the "porcelain") of JJ is not backwards-compatible with that of Git, even though it can use git's "plumbing". `jj commit` works differently than `git commit`, and Git can't match that without a similar compatibility break. JJ uses Git's "content-addressed DAG of snapshots" data model in a particularly elegant way, and deletes many redundant commands to achieve that elegance. Git could absolutely delete half of its interface & change much of the rest to get that, but then it'd break lots of scripts & third-party tools. JJ namespaces the UI redesign, which allows breaking that compatibility without breaking everyone's workflow at once. People can switch (or not switch) independently, where a Git UI redesign would have to be adopted by everyone together.

It's trivial that JJ can't do anything `git` can't do, because JJ uses Git as a backend, so everything it does it does via `git`. But Git the project is extremely unlikely to alter `git` the tool to provide JJ's interface, and even if they did via namespacing it (e.g. `git jj commit`, `git jj git init --colocate`, etc.) that'd just be adding even more commands on top of the existing interface with too many commands.

Re: I see a future in jj

#260

Post by Gormo »

CuriouslyC wrote: post #248
jtwaleson wrote: post #173

I have Luddite feelings reading about alternatives to Git. As an industry we have soooo many languages, frameworks, tools, distros etc. It's like we are pre metric system or standardization on screw thread sizing. I am really happy that at least for VCS, we have a nearly universal solution in Git, except for the big tech folks. Sure, jj might solve some issues, but once it gets serious traction, all the tooling that…

Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over, as its footgun elements get magnified when you have a lot of agents working on one codebase at once. I dislike jj as move forward because I don't think it goes far enough for the amount of friction moving to it as an industry would entail. The next generation of VCS should be atomic, with a proper database tracki…

> Git absolutely is a productivity drain and should be replaced, particularly as agentic coding takes over,

Is this an oblique way of saying that Git should not be replaced?

Post reply on HN