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

jj – the CLI for Jujutsu

steveklabnik.github.io

Post reply on HN
Print view View original

171–180 of 517 posts

Re: jj – the CLI for Jujutsu

#171

Post by alunchbox »

tom_alexander wrote: post #6

I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you creat…

if you loose an edit jj op log is incredible, I've saved a ton of work more-so now with AI's making mistakes. Also workspaces are super fast compared to git worktree's - same concept, different implementation.

I agree, that was a bit of an interesting approach but more-so than not it's been better in DX even though you have to 'unlearn' long term it's been a benefit IMO, but a soft one, not something you can measure easily.

Re: jj – the CLI for Jujutsu

#172

Post by aseipp »

nomel wrote: post #104
smweber wrote: post #42

Earlier quoted context omitted.

jj edit is the biggest jj footgun I can think of, as other comments said just use jj new. But also if you do accidentally edit or change something jj undo works surprisingly well. I found when using jj it worked best for me when I stopped thinking in commits (which jj treats as very cheap “snapshots” of your code) and instead focus on the “changes”. Felt weird for me at first, but I realized when I was rebasing with…

> preventing you from accidentally rebasing changes that have been shared. I think this ruins it for me then. I push my in-progress work, to my in-progress branches (then git-squash or whatever later, if needed). It makes switching between (lab) computers, dead or not, trivial. Is there some "live remote" feature that could work for me, that just constantly force pushes to enabled branches?

Yes, almost all JJ users do this constantly. Just "track" the particular branch. JJ has an idea that only some commits are immutable, the set of "immutable heads", and the default logic is something like "The main branch is always immutable, remote branches are immutable, 'tracked' remote branches are mutable." In other words, tracking a remote branch removes it from the set of immutable heads.

So just run:

    jj bookmark track myname/somecoolfeature --remote origin
and the default settings will Do What You Want. This is intended as a kind of safeguard so that you do not accidentally update someone else's work.

Some people configure the set of immutable heads to be the empty set so they can go wild.

Re: jj – the CLI for Jujutsu

#173

Post by steveklabnik »

zingar wrote: post #117

"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.

This is good feedback, for sure, thank you. It's sometimes hard to come up with truly concise examples, but that's also why they're so valuable.

Re: jj – the CLI for Jujutsu

#174

Post by vaylian »

octocop wrote: post #157

Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.

You could have said the same thing about subversion.

Subversion is a fine VCS. But git offers a better approach with being offline-first and decentralized. It also makes merging branches a lot easier.

I don't know enough about jj to praise it, but I don't think git will be the last VCS that will become widely popular.

Re: jj – the CLI for Jujutsu

#175

Post by ersatz-matty »

zingar wrote: post #117

"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.

Consider using the table of contents on the left of the page to view "Real World Workflows", "Branching, Merging, and Conflicts", and then "Sharing Your Code with Others" and then evaluate how JJ does things against your current git workflow. This requires some minor effort on your part.

The official JJ docs also have a "bird's eye view" introduction and tutorial available here: https://docs.jj-vcs.dev/latest/tutorial/.

EDIT: Jujutsu for Git experts: https://docs.jj-vcs.dev/latest/git-experts/>. This outlines some of the main advantages relatively succinctly.

Re: jj – the CLI for Jujutsu

#176

Post by Philpax »

SV_BubbleTime wrote: post #126

>You can request to not use the pager by using jj st --no-pager, or if you hate the pager and want to turn it off, you can configure that with $ jj config set --user ui.paginate never In one feature they can’t help themselves from calling it two different things already. Why do this? Why can’t the very clearly smart people making things step 1/2 step outside themselves and think about it like they are the users they…

1. Pagination with a pager is a reasonable default. See `git log`.

2. The native format would be `jj init`. For precedent, see how uv dealt with its pip compatibility: `uv pip install` was obsoleted by `uv add`.

Re: jj – the CLI for Jujutsu

#178

Post by joshuamorton »

saghm wrote: post #113
embedding-shape wrote: post #63

Earlier quoted context omitted.

> Just don't ever use `edit`, use `new` instead As a git-ist (?), if I'd ever move away from git, it would be to avoid tooling that has idioms like this (like git too has), if `jj` just gonna surface a bunch of new "bad ideas" (together with what seems like really good ideas), kind of makes it feel like it isn't worth picking up unless you don't already know git.

The idiom here is use `edit` if you want to edit a commit, and use `new` if you want to make a new commit. This works identically whether you specify the commit via branch name or commit id. I'm not sure why people are saying not to use `edit` ever. It's basically just a shorthand for staging and amending changes in an existing commit, and there's still a use case for that; it's just not "I want to see the changes on…

I think it's because it's easy to make annoying mistakes (still easy to fix with undo) with edit. And it gains relatively little over new+squash. Edit is a useful power-feature, but I think for a novice, "never use it, only use the more well understood workflow of new+squash" is a good heuristic.

Re: jj – the CLI for Jujutsu

#179

Post by latortuga »

zingar wrote: post #117

"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.

Yeah we moved on from SVN to git because SVN branches were truly a pain in the ass to work with. I truly do not have any rough edges or big pains in my day to day git workflow.

Re: jj – the CLI for Jujutsu

#180

Post by rs545837 »

jj is genuinely great and I think it deserves way more adoption than it has right now. The mental model is so much cleaner than git, undo actually works the way you'd expect it to, and working with stacked changes feels natural instead of that constant low-grade anxiety of actually breaking something. It's probably the best frontend for version control that exists today.

For the last few months though I've been thinking a lot about what you said at the end there. What if version control actually understood the code it was tracking, not as lines of text but as the actual structures we write and think in, functions, classes, methods, the real building blocks? A rename happening on one branch and an unrelated function addition on another aren't a real conflict in any meaningful sense, they only look like one because every tool we have today treats source code as flat text files.

For enhancing this kind of structural intelligence I started working on https://github.com/ataraxy-labs/sem, which uses tree-sitter to parse code into semantic entities and operates at that level instead of lines. When you start thinking of code not as text there's another dimension where things can go, even a lot of logic at the comiler level with call graphs becomes useful.

Post reply on HN