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

461–470 of 517 posts

Re: jj – the CLI for Jujutsu

#461

Post by MrGreenTea »

8n4vidtmkvmk wrote: post #448
ibejoeb wrote: post #420

A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage: On a clean repo: $ jj The working copy has no changes. Working copy (@) : abcdef a53ff9ba (empty) (no description set) Parent commit (@-): qrstuv 4bc1bf34 the last thing…

Sometimes i like to jj describe before writing any code. It helps with mental clarity what i intend on writing or helps if i have to run away mid coding session (description will show in log so i can find it again) In this scenario I'd instead jj new at the end, after im finished and ready to move on to the next thing.

You can then also just use `jj commit`. It will see the existing commit message and just move to a new clean revision.

Re: jj – the CLI for Jujutsu

#462

Post by menaerus »

skydhash wrote: post #442
ibejoeb wrote: post #435

Earlier quoted context omitted.

You could. That's not the point. I suggesting that if you want to try jj, try it based on its affordances, not by comparing it to how you'd do it differently with git. Most of the tutorials start with git and try to teach you how to change your thinking. I think the project would find many more fans if it didn't make such a big deal about being kinda like git.

I did try it, but it was not my cup of tee. Git fits my mental modal better. Branches are experiments, commits are notes in my lab notebook, stashes are notes in scrap of papers, the staging area is for things that I plan to note down and the working tree is the workbench. Then every once in a while I take the notebook and rewrite stuff in it or update it to fit recent changes in the canonical branches. I use magit s…

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.

Re: jj – the CLI for Jujutsu

#463

Post by SiempreViernes »

miyoji wrote: post #302
SiempreViernes wrote: post #140

Earlier quoted context omitted.

git promises "version control", this clearly implies that the versions predate the control: in this picture the git workflow is not backwards.

I don't think the term "version control" has any implication about precedence, and I don't understand what you mean by "the versions predate the control". In git, you add items to the worktree (control), then you commit (create a version), so doesn't that mean git does it "wrong" according to what you're saying? In jj, you are always on a committed version and the contents of that commit are controlled by your edits,…

The versions of importance are the changes made outside of git, not the internal bookkeeping of the version control software itself.

Re: jj – the CLI for Jujutsu

#465

Post by aubanel »

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?

Re: jj – the CLI for Jujutsu

#466

Post by oniony »

menaerus wrote: post #462
skydhash wrote: post #442

Earlier quoted context omitted.

I did try it, but it was not my cup of tee. Git fits my mental modal better. Branches are experiments, commits are notes in my lab notebook, stashes are notes in scrap of papers, the staging area is for things that I plan to note down and the working tree is the workbench. Then every once in a while I take the notebook and rewrite stuff in it or update it to fit recent changes in the canonical branches. I use magit s…

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 just hop around the tree with gay abandon. That alone is invaluable.

Then add in the fact that a change to history gets rippled down the descendent commits. And the fact that conflicts are recorded in the history and can be dealt with at your leisure. Or the fact that `jj undo` is a thing.

Re: jj – the CLI for Jujutsu

#467

Post by whytevuhuni »

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…

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

Re: jj – the CLI for Jujutsu

#468

Post by busfahrer »

ibejoeb wrote: post #420

A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage: On a clean repo: $ jj The working copy has no changes. Working copy (@) : abcdef a53ff9ba (empty) (no description set) Parent commit (@-): qrstuv 4bc1bf34 the last thing…

> Don't think about git.

You can also make the reverse point, only think about git:

In theory it's perfectly possible if you have to jj binary lying around somewhere, to not even use it as your git client, but to temporarily do a `jj git init --colocate`, do a complex restructuring of your repo across 3 branches, and then delete the .jj folder again :-)

Just to highlight the other end of the spectrum, jj is flexible like that

Re: jj – the CLI for Jujutsu

#469

Post by busfahrer »

smackmybishop wrote: post #8
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…

Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.

Once you get your head around it a bit, doing a new in this circumstance will be second nature, since you will have realized that a `new XYZ` in jj leads to the same underlying git state as a `git checkout XYZ` in git

Re: jj – the CLI for Jujutsu

#470

Post by misnome »

rstuart4133 wrote: post #446
misnome wrote: post #251

The problems with jj that led me to abandon are: - All of everything good about it breaks down the instant you want to share work with the outside world. It's git on the backend! Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. And in doing so, you lose almost everything t…

> Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. All true. I ended up writing my own `jj push` and `jj pull` aliases that automated all this. They aren't simple aliases, but it worked. `jj push` for example "feels" very like `git push --force-with-lease`, except if you'v…

> True, but how is this different to any other VCS?

What other VCS behaves this way by standard? If it's not in e.g. .gitignore "git status" will show that it's aware of it, but won't automatically absorb them into the commit? https://github.com/jj-vcs/jj/issues/5596 doesn't seem to be the oldest instance of this problem, but does seem to be the current discussion, and there seems to be no consensus on how to fix.

Oh, and ISTR submodules were a pain to work with.

Edit: https://github.com/jj-vcs/jj/issues/323#issuecomment-1129016... seems likely to be the earliest mention of this problem

Post reply on HN