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 you did

Make some changes.

    $ jj # shows status (new, modified, deleted, moved, etc.)

If you're satisfied with your changes,

    $ jj commit -m "made changes"
    

Now `jj` is back to clean state. You don't need to do `jj new` to continue working linearly. Just make your next changes and commit. If you realize that you messed something up, fix it, then `jj squash` and it gets incorporated into that last commit.

You only `jj new -r lmnop` if you want to do some work based on the state of the codebase at revision lmnop, rather than the previous revision, which is a figurative branch. No need to manually create and name branches.

As for git history: just do `git log` to see what's actually going on. It's a clean history reflecting your `jj commit`s. You're not going to see all of the stuff the jj machinery does.

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.

> 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

Colocation is the default these days, so you don't even need that flag :)

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.

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 so the actual operations are just a few quick key presses.

I could probably do the same thing with jj, but why use a new tool when the old thing works well, has myriad of integrations, and it's fairly standard.

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.

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.

Maybe. Different organisations work at different paces and with different contention rates. If you're on a small team and less being tugged about then you might not find value with this stuff.

But I frequently have cases where I have some changes I'm making to repo `acme`. I'll put a PR up for review and then I'll start on a second PR for the same repo. I stack these commits on top of my previous PR. If I then notice a problem in the earlier work I can easily fix it and have the changes ripple down to the later PR. Or if somebody else merges something in against `main` it's really easy using `jj rebase` to move my commits against the new version of `main`. With a single `jj rebase` I can move all of my stacked PRs over to the new version of `main` and have every stacked PR updated.

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

Yes, exactly that. In Jujutsu you don't have Branches like you do in Git. You have branches in the sense that you have forks in the tree and you can place a "bookmark" against any revision in that tree. (When exporting to a Git repo those bookmarks are mapped to Git branch heads.)

So yeah if I have revision `a` with two children `b` and `c`, and even if those children have their own children, a change to `a` will get rippled down to `b` and `c` and any further children. It's a bit like Git rerere if you've used it, except you're not forced to fix every conflict immediately.

Any conflicts along the way are marked on those revisions, you just fix the earliest conflicts first and quite often that'll ripple down and fix everything up. Or maybe there'll be a second conflict later down the stack of commits and you'll just fix that one the same way.

To fix a conflict you typically create a new revision off the conflict (effectively forking the tree at that point) using `jj new c` (let's call the result `cxy`) fix the revision in that commit and then you can `jj squash` that revision `cxy` back into `c`. This, again, gets rippled down fixing up all of the descendent commits.

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.

Some of jj's users are "I find git hard and like jj more" but a lot of us are/were git experts before switching.

Yes, I understand that but what I'm saying is that the problem definition isn't completely clear to me. I'm not saying that there is none, it's just that it may not be obvious at the first read.

Ah, no worries.

I don't think the notion of subscription is off-putting. It's just not a very natural fit for something that isn't a function of time or resources. This is just a better model for upgrades. If you make improvements later on, people will pay again.

For this particular situation, your risk probably isn't that people will stop paying. It's more likely that people like it enough that a free alternative pops up (it's not so different from rectangle and alttab.) You're probably better off taking the money up front.

The point is valid, but that's typically the way it is. "You can't enjoy the benefit but the detriment is all yours" is how the federal government generally operates.

I'm a little afraid of the failure modes, frankly. Clever, but that seems like it would b likely to exercise some under-tested timing situations. I'm not familiar with that API, so take the hunch with a grain of salt.

It depends on how it's implemented. If it's a fixed window, then your absolute ceiling is tokens/windows in a month. If it's a function of other usage, like a timeshare, you're still paying for some price for a month and you get what you get without paying more per token. There's an intrinsic limit based on how many tokens the model can process on that gpu in a month anyway, even if it's only you.

> they're losing Iran war.

What criteria are you using for this assessment?

> What criteria are you using for this assessment?

We lost the moment we started because we went on a whim and without a cohesive strategy. This was a stupid stupid thing to do, and the longer it goes on the more obvious it becomes that this administration has no idea what it is doing.

Pool's closed.

If we look at the stated goals (as inconsistent as they have been):

Unconditional surrender -> nope Regime change via popular uprising -> nope Destruction or removal of enriched uranium -> nope Destruction of drones and ballistic missile capability -> nope

Final goal of getting back to the pre-war state (which is admitting loss in itself):

Reopen in the straight of Hormuz -> nope

So no objectives have been achieved, and although you could argue they will be in the future, this seems increasingly unlikely in the short timeline the Trump admin has given themselves. It any of them were possible at all, which seems doubtful.

They unironically relaunch it as XBox Copilot tomorrow...

> BUG 2: every time you use --resume, your entire conversation cache rebuilds from scratch. one resume on a large conversation costs $0.15 that should cost near zero.

I use it with an api key, so I can use /cost. When I did a resume, it showed the cost from what I thought was first go. I don't think it's clear what the difference is between api key and subscription, but am I believe that simply resuming cost me $5? The UI really make it look like that was the original $5.

You have to actually send something

It's certainly about their lives, but it's also about not tanking the program due to catastrophic failure. The astronauts are going to do it regardless of the risk.

I'm pretty much with you. The fraud and waste is infuriating. But, frankly, what is the point of this program? At the risk of not being skeptical, can't we say that we conquered lunar orbit in the 1960s? I don't understand why this is some enormous scratch R&D project.