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

241–250 of 336 posts

Re: I see a future in jj

#241

Post by steveklabnik »

1718627440 wrote: post #211
aardvark179 wrote: post #175

Earlier quoted context omitted.

Crucially you can also select a region within a chunk and perform those commands, so it’s easy to untangle changes.

And you can even edit the content you stage, so that you can stage something different, than what is in the working tree. Having different content in the index vs. working tree is the feature of the index, which I think JJ just doesn't support?

jj doesn’t support it in the sense that there’s no special index feature. You can use a workflow where you have a commit represent the index (and that’s basically the most common workflow). This means you don’t need a separate feature, you just use the tools that slice and dice any commit with your “index”.

Re: I see a future in jj

#242

Post by skydhash »

baq wrote: post #235
skydhash wrote: post #234

Earlier quoted context omitted.

In magit, the diff is splitted into sections: Untracked, Unstaged and Stage. The sublevels are files then hunks. You can stage and unstage hunks, files and whole section by pressing s and u. Pressing k discards the node (section, file, or hunk. You can also stage or unstage lines by selecting them first and press the relevan keys. If you press ‘return’ on a hunk, it brings you directly the the line to edit.

jj wouldn't have any issues with supporting this workflow, if you could replace magit's git commands with some jj ones it'd probably just work. IOW the only thing that's missing is elbow grease. actually, with jj's seamless rebases, it'd work exactly as you'd want it to (but maybe not how you'd expect if you're used to the git way) when aimed at a commit in the middle of a branch: pick lines which stay below, above o…

The thing is that magit have a lot of commands that makes rebasing a breeze. Pressing c, then s, will allow you to select interactively (from the commits log) a commit to target when doing autosquash. That will create a new commit with the relevant message. Pressing c, the S (shift+s), will rebase immediately, squashing the current staging area into the selected commit.

Interactive rebasing is a breeze. Editing commits is very fast (reordering, dropping rewording, splitting,…). Same with dealing with merge conflicts (Emacs have various merge packages builtin).

The same speed Vim brings to editing, that’s nearly the same speed you get with magit for git.

Re: I see a future in jj

#243

Post by steveklabnik »

pm215 wrote: post #223
chrchr wrote: post #164

Earlier quoted context omitted.

There's more than one way to do it, but the very normal UX is that you can just scroll through the diff file-by-file and stage/stash/drop each hunk individually by placing your cursor over it and issuing the appropriate command. You can do the same with files, staging/stashing/dropping changes to a file by placing the cursor on its name and issuing a command.

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.

Re: I see a future in jj

#244

Post by steveklabnik »

1718627440 wrote: post #215
Pet_Ant wrote: post #72

One thing I've wanted is the ability to group commits into a mega commit. So the history of little changes remains, but as you are scrolling you don't see all of them.

That's called a merge commit. You can even group them further by creating merges of merge commit. It requires you to merge in the right direction though.

That doesn’t really hide them in the UI though.

Re: I see a future in jj

#245

Post by jtwaleson »

mpalmer wrote: post #237
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…

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 Windows and Linux (Debian, Arch, Ubuntu, etc). Teams do it, and it's all possible, but it was nice that at least everyone used git.

Re: I see a future in jj

#246

Post by steveklabnik »

archargelod wrote: post #196
jmercouris wrote: post #39

After reading the article, the technical merits of `jj` are completely unclear.

The article can be summarized to essentially: I like Rust. jj is written in Rust. Some Rust person loves jj. jj is used at Google. Who upvotes this?

I can’t speak to people’s motivations, but I have been a very active member on this forum for a long time, and I was on the Rust team for about a decade, beginning before 1.0.

So the article is more like “Here’s why I started using Rust. If you thought I made a good choice then, well, I’m making a similar choice in case you want to join me.” Seems people find that compelling.

Just like Rust’s success was not inevitable, neither is jj’s. But I think it might work out.

You could also consider this a disclosure of sorts, I post a lot on this forum about jj (and Rust), and so knowing that I now have a financial incentive is important context to some people.

Re: I see a future in jj

#247

Post by lowboy »

leftyspook wrote: post #236
lowboy wrote: post #100

Earlier quoted context omitted.

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

> I'm not 100% clear on what you mean here The core of their complaint is that if you use `jj edit` it's not obvious how to get a diff of what you did. The answer, of course, is that you can use `jj evolog -p`.

Ah, yes that reading of the “work is invisible” is likely.

Re: I see a future in jj

#248

Post by CuriouslyC »

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 tracking atoms, and "plans" to construct repo states from atoms. A VCS built around these principles would eliminate branching issues (no branches, just atoms + plans), you could construct relationships from plan edit distances and timestamps without forcing developers to screw with a graph. This would also allow macros to run on plans and transform atoms, enable cleaner "diffs" and 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.

The downside of an atomic design like this is you have to parse everything that goes into VCS to get benefits, but you can fallback to line based parsing for text files, and you can store pointers to blobs that aren't parseable. I think the tradeoff in terms of DX and features is worth it but getting people off git is going to be an epic lift.

Re: I see a future in jj

#249

Post by baq »

skydhash wrote: post #242
baq wrote: post #235

Earlier quoted context omitted.

jj wouldn't have any issues with supporting this workflow, if you could replace magit's git commands with some jj ones it'd probably just work. IOW the only thing that's missing is elbow grease. actually, with jj's seamless rebases, it'd work exactly as you'd want it to (but maybe not how you'd expect if you're used to the git way) when aimed at a commit in the middle of a branch: pick lines which stay below, above o…

The thing is that magit have a lot of commands that makes rebasing a breeze. Pressing c, then s, will allow you to select interactively (from the commits log) a commit to target when doing autosquash. That will create a new commit with the relevant message. Pressing c, the S (shift+s), will rebase immediately, squashing the current staging area into the selected commit. Interactive rebasing is a breeze. Editing commi…

It sounds like it’d would work even better with jj is all I’m saying. A rebase UI doesn’t mean a git rebase UI.

Re: I see a future in jj

#250

Post by ratrocket »

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%?

One way I compare the git to jj transition (if it happens, or for whom it happens) to the svn to git transition is: branching in svn was awful. It was heavyweight and you were signing up for pain later down the road. Git made branching easy and normal, almost something you barely need to think about. jj does a similar thing for rebasing. For someone whose familiarity with git is clone, pull, push, merge, creating branches (so, basic/working/practical familiarity but even "rebase -i" might be pushing the limits)- for someone like that what jj offers is a similar "lift" of a feature (rebase) from "scary" to "normal" similar to what git did for branching compared to svn.

That's just one aspect of the whole thing, and of course if you're a git rebase wizard (or have tools that make you that) then this won't seem relevant. But I think for a lot of people this might be a salient point.

Post reply on HN