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

471–480 of 517 posts

Re: jj – the CLI for Jujutsu

#471

Post by ncphillips »

oniony wrote: post #466
menaerus wrote: post #462

Earlier quoted context omitted.

The problem jj is trying to solve is not entirely clear to me but I guess there is enough people who aren't able to find their way with git so for them it probably makes switching to jj more appealing, or at least that's my first impression without going too deep into the documentation.

I wouldn't say it's that people are not able to find their way with Git. I was a competent Git user and would carefully and squash my commits. It's just easier and nicer with Jujutsu. The way all changes (except those in the ignore file) are automatically incorporated into the current commit means I don't have to faff about with stash when I need to pivot and then try to remember which commit to pop against. I can ju…

There must be some kind of split in how people work or something. I’ve never had the desire to jump around the git tree. I never squash commits. I basically never stash changes. All the things that people say jj makes easier are things I never even want to do. Not because they’re not easy with git, but because it sounds hard to keep straight in my head.

Re: jj – the CLI for Jujutsu

#472

Post by ncphillips »

medler wrote: post #428
embedding-shape wrote: post #144

Earlier quoted context omitted.

> Just don't ever use `edit`, > The idiom here is use `edit` if you want to edit a commit You know, you guys have fun with that, I'll continue using git which (probably) has the same amount of warts, but I already know them. I'll continue to refer new VCS users to jj, seems a lot easier to learn, but really don't have the interest to re-learn a bunch of ever-changing idioms.

jj has far fewer warts than git. You don’t have to learn every jj idiom, you just have to find a workflow you like, which you will, quickly, because it’s so easy to use. Personally I don’t know why anyone uses `edit` but if they like it then I’m happy for them.

But I have a workflow I like with git and I can’t see how jj would be better. I’m genuinely curious as to whether it would be or not, but the behaviours people are describing are not things that interest me.

Re: jj – the CLI for Jujutsu

#473

Post by willhbr »

whytevuhuni wrote: post #467
oniony wrote: post #466

Earlier quoted context omitted.

I wouldn't say it's that people are not able to find their way with Git. I was a competent Git user and would carefully and squash my commits. It's just easier and nicer with Jujutsu. The way all changes (except those in the ignore file) are automatically incorporated into the current commit means I don't have to faff about with stash when I need to pivot and then try to remember which commit to pop against. I can ju…

> Then add in the fact that a change to history gets rippled down the descendent commits. This sounds interesting. Could you go into a bit more detail? I have 3 branches off of a single commit, update that commit, and all branches automatically rebase? Or?

Yep they automatically rebase. If that creates conflicts it's marked on the child commit and you can swap over and resolve it any time.

Re: jj – the CLI for Jujutsu

#474

Post by Balinares »

skydhash wrote: post #436
Balinares wrote: post #423

Earlier quoted context omitted.

In sort of the same way juggling apples is better than juggling hand grenades: it's mostly the same in the simple cases, but once you start doing the really fancy stuff, one of the two will get you a lot fewer messy explosions. (Your question is not dumb, BTW. The pithy answer is: UX matters , but it does so in ways that can be hard to convey since it's about the amount of cognition you need to put in a given thing t…

You have to put a lot of effort to mess up a git repo. So I'm not seeing the allusion to hand grenades.

I'm glad to hear you never encountered the kind of quagmire that can occur around e.g. non-trivial conflicts while rebasing a chain of git commits. On large enough codebases, those can be common.

Re: jj – the CLI for Jujutsu

#475

Post by Balinares »

jeremyjh wrote: post #96
maleldil wrote: post #83

Earlier quoted context omitted.

If you constantly switch between the two, you're going to have a hard time, but you can take a git repo, try jj for a while, and if you decide to go back, you don't lose anything.

Right, but that’s different from working in a team environment where everyone else continues using git.

I don't understand what you mean. The team I currently work with is 100% git while I only use jj anymore, and I've had zero issues?

Re: jj – the CLI for Jujutsu

#476

Post by aryehof »

tiborsaas wrote: post #54

Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…

> Does JJ really prefer for me to think backwards?

Perhaps it’s the other way around. I have a standard agentic instruction to summarize prompt instructions using jj describe. After it makes changes I can see both the file changes made and a log description of what prompted those changes. When done it’s just jj new and its ready for the next set of prompts.

Re: jj – the CLI for Jujutsu

#477

Post by nightski »

MrJohz wrote: post #447
skydhash wrote: post #438

Earlier quoted context omitted.

> Now put yourself in the shoes of a git novice Sometimes it seems to me that's only in SWE we allow people to proceed in the workplace without any training. There's enough learning material that people should take a week or something to practice git and not be git novice anymore.

Or you make tools that are easier to use, so that you can spend that week learning something more useful than the finicky details of branch vs detached head checkouts.

Don't get me wrong, git has some accidental complexity (as will any tool introduced, including what I am seeing with jj). But a lot of it is just incidental complexity. It doesn't matter how much lipstick you put on it, at the end of the day some concepts need to be learned.

Re: jj – the CLI for Jujutsu

#478

Post by [deleted] »

saghm wrote: post #455
nightski wrote: post #431

Earlier quoted context omitted.

Except it's not an unrecoverable error. If you do it all it does is add that file to the working index. No commits are made and no harm is done. So no, I do not feel it's the same as a null pointer exception or type mismatch.

> If you do it all it does is add that file to the working index. No, that's not at all what it's doing! git init touch foo.txt git commit -m 'empty foo.txt' echo something >> foo.txt git diff --stat # Shows one line added to foo.txt git checkout foo.xt git diff --stat # empty output; no changes! It removes changes that are not yet checked in. You can only get them back by going into the reflog (which is pretty much…

[deleted]

Re: jj – the CLI for Jujutsu

#479

Post by hi-im-buggy »

aubanel wrote: post #465

Does jj work well with parallel agents? The current problem that I often have is that I want to work on several things in parallel through several agents, always forget to do worktrees, then the different branches of work tend to step on each other Does JJ make it simpler?

jj supports workspaces, akin to git's worktrees. They've felt pretty natural for me to use.

The only caveat is that if you're in jj repo that uses git colocation, only your main workspace will have a `.git/` directory. When you have other infra set up that assumes you're in a valid git repo, this can be a little annoying.

Post reply on HN