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

431–440 of 517 posts

Re: jj – the CLI for Jujutsu

#431

Post by nightski »

saghm wrote: post #409
nightski wrote: post #323

Earlier quoted context omitted.

I stand corrected by this one scenario, but I’ve been using git for over a decade and never found that useful. Just don’t use checkout on a file path, there is no need.

"Just don't accidentally do things wrong" is also the way to avoid null pointer errors, type mismatches in dynamically typed languages, UB in C/C++. It works, until it doesn't, and in practice that happens pretty quickly. Personally, I like things that have proper safety checks.

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.

Re: jj – the CLI for Jujutsu

#432

Post by rstuart4133 »

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…

> so you need to defensively create empty new commits for your changes.

I thought that for a long while too, and was equally pissed. Then I happened upon `jj evolog`. Turns out jj had a better solution than staging all along - I just didn't realise it existed.

The move from using jj as an alternate porcelain to git to using it efficiently took me more months than I care to admit. I suspect being familiar with git cli is actually a handicap in learning jj. New users without pre-conceptions will have a much easier time of it.

And oddly, I also suspect they will also end up knowing more about the underlying git storage engine than git users. It turns out it's capable of being used far more effectively than git uses it.

Doubly oddly, I blame Linus's familiarity with CVS and SVN for that. He (correctly) bemoaned how unsuited to the job of distributed source code management they were and invented a storage engine that has proved to be remarkably good at the job. But he carried across many the concepts in their CLIs to gits porcelain. Jj (with a lot of help from hg), finally broke free of that legacy.

Re: jj – the CLI for Jujutsu

#433

Post by rstuart4133 »

steveklabnik wrote: post #342
verdverm wrote: post #338

Earlier quoted context omitted.

The git compatibility page states that submodules are not supported https://docs.jj-vcs.dev/latest/git-compatibility/

What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet. This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.

> and it does, in my understanding, work.

I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly.

They can take all the time in the world to implement submodules as far as I'm concerned. jj's implementation of workspaces removes all of the hairs of git's worktrees. git submodule implementation has even more hairs than worktrees. If the jj developers need time to do as good a job on submodules as they did with workspaces, then I say give it to them.

Re: jj – the CLI for Jujutsu

#434

Post by skydhash »

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…

If I really wanted that, I could create an alias like

  alias.save="!git add -A; git commit -m"
And then use

  $ git save "made changes"

Re: jj – the CLI for Jujutsu

#435

Post by ibejoeb »

skydhash wrote: post #434
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…

If I really wanted that, I could create an alias like alias.save="!git add -A; git commit -m" And then use $ git save "made changes"

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.

Re: jj – the CLI for Jujutsu

#436

Post by skydhash »

Balinares wrote: post #423
motbus3 wrote: post #136

Earlier quoted context omitted.

I am dumb. why is that better than a git branch or a git worktree ?

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.

Re: jj – the CLI for Jujutsu

#437

Post by tiltowait »

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…

I tend to approach jj commits as local PRs. Decide what it is I'm working on, make a new, empty commit on top of that :

    jj new -m 'do thing'
    jj new
As I work on the "local PR", I `jj squash` my working changes into the named commit. By keeping my working commit description-free, I avoid accidentally pushing it (and potentially broken code) to origin.

Re: jj – the CLI for Jujutsu

#438

Post by skydhash »

MrJohz wrote: post #421
fragmede wrote: post #390

Earlier quoted context omitted.

My command looks like either: fragmede@laptop:(abranch)~/projects/project-foo$ or fragmede@laptop:(abcdef)~/projects/project-foo$ Depending on if abranch is checked out, or abcdef which may be HEAD of abranch is checked out. If you're having to run `git status` by hand to figure out which of the two states you're in, something's gone wrong. (That something being your PS1 config.) If people are having trouble with tha…

The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same. Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is chec…

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

Re: jj – the CLI for Jujutsu

#439

Post by SAI_Peregrinus »

jampekka wrote: post #345
SAI_Peregrinus wrote: post #309

Earlier quoted context omitted.

You have a DAG of "changes" to the repo state. Each change has a stable ID, you can modify its contents or description without changing the ID. There's always a "current" change checked out, JJ automatically snapshots your edits to files into this change. JJ provides tools to edit changes, describe them, group them into named branches (bookmarks), reorder them, split them apart, etc. JJ defaults to being backed by gi…

That sounds a bit faffy. In solo or small team work git is often git pull, edit code, git commit -a, git push. With jj you have to fetch, start new space off a bookmark, edit code, commit it, update the bookmark and finally push?

Git pull equivalent is `jj git fetch`

Git `checkout -b` equivalent is `jj bookmark create`

`git commit -a` equivalent is `jj commit`

Git push equivalent is `jj git push`

No more faff than git, I just prefer to do things in a slightly different order. I don't usually name the branch (`git checkout -b` equivalent) until after I'm done making changes & ready for a PR. I prefer to make changes, try things out, get it working, and then rearrange the commits to have a clean history to make my reviewer's lives easier. With `git` that's an interactive rebase, which tends to require a lot of faffing about.

JJ doesn't require branches to have names. By default it just leaves bookmarks (names of branches, roughly) where they are when new changes are made, but that's easily configured. You can even have it automatically create names when you push.

Re: jj – the CLI for Jujutsu

#440

Post by rstuart4133 »

stouset wrote: post #239
IshKebab wrote: post #213

Earlier quoted context omitted.

It is when I tried it.

Jujutsu uses git as its primary backing store and synthesizes anything else it needs on top on-the-fly. Any incompatibility here is considered a serious bug. Obviously I can’t argue against your lived experience, but it is neither typical nor common. This is quite literally an explicitly-supported use, and one that many people do daily.

> Obviously I can’t argue against your lived experience, but it is neither typical nor common.

I consider myself a proficient jj user, and it was my lived experience too. Eventually you get your head around what is going on, but even then it requires a combination of jj and git commands to bring them into sync, so `jj status` and `git status` say roughly the same things.

The friction isn't that jj handles state differently, it's that `jj git export` doesn't export all of jj's state to git. Instead it leaves you in a detached HEAD state. When you are a newbie looking for reassurance this newfangled tool is doing what it claims by cross checking it with the one you are familiar with, this is a real problem that slows down adoption and learning.

There are good reasons for `jj git export` leaving it in a detached head state of course: it's because jj can be in states it can't export to git. If we had a command, say `jj git sync` that enforced the same constraints as `jj git push` (requiring a tracked branch and no conflicts) but targeted the local .git directory, it would bridge the conceptual gap for Git users. Instead of wondering why git status looks wrong, the user would get an immediate, actionable error explaining why the export didn't align the two worlds.

Post reply on HN