A good way to think of it is that jj new is an empty git staging area. There's still a `jj commit` command that allows you to desc then jj new.

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

jj split allows you do to this pretty well.

> Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.

In jj you always have a commit - it's just sometimes empty, sometimes full, has a stable changeid regardless. jj treats the commit as a calculated value based on the contents of your folder etc, rather than the unit of change.

I find it reasonably good with lots of tweaking over time. (With any agent - ask it to do a retrospective on the tool use and find ways to avoid pain points when you hit problems and add that to your skill/local agents.md).

I expect git has a lot more historical information about how to fix random problems with source control errors. JJ is better at the actual tasks, but the models don't have as much in their training data.

When reviewing, you can also mark individual files as reviewed (useful in larger reviews where you're incrementally reviewing files). If you do this, only files that are changed will be expanded when you come back to the review.

I agree with your point that most flags should generally treat short versions as exact aliases to long flags, but I just think that a convention that treats -h and --help as concise vs long is 100% reasonable. The distinction is often breadth vs depth.

Initial impression:

-h and --help should follow the short / long standard of providing more / less info. The approach currently used is -h and --help show command lists and point at a --help-full flag. The --help-full output seems to give what I'd expect on -h. This needs to be much better - it should give enough information that a user / coding agen doesn't have to read websites / docs to understand how the feature works.

Completions are broken by default compared to the actual list of commands - i.e. dns didn't show up in the list.

When I ran cf start -h it prompted to install completions (this was odd because completions were already installed / detected). But either way, -h should never do anything interactive

Some parts of the cli seem very different to the others (e.g. cf domains -h is very different to cf dns -h). Color / lack of color, options, etc.

This stores a lot of interesting things outside of the repository of knowledge and then throws it away. This seems unfortunate.

- https://github.com/charmbracelet/bubbletea

- https://github.com/charmbracelet/bubbles

- https://github.com/charmbracelet/lipgloss

"Terminal, Konsole, PuTTY, Xresources, XRDB, Remmina, Termite, XFCE, Tilda, FreeBSD VT, Terminator, Kitty, MobaXterm, LXTerminal, Microsoft's Windows Terminal, Visual Studio, Alacritty, Ghostty, and many more."

You may have used data from it without knowing about it.

- colors are fairly natural

- background and black are distinct

- grays are naturally ordered avoiding full black

- light and dark colors are distinct from each other

- all colors look good on background, black, dark gray, gray, white

We use this for all the screenshots on https://ratatui.rs and https://github.com/ratatui/ratatui

It's available from the usual places https://iterm2colorschemes.com/, https://windowsterminalthemes.dev/?theme=Aardvark%20Blue, built in to ghostty, extension for vscode etc.

[1]: https://github.com/mbadolato/iTerm2-Color-Schemes/pull/417

1. Here's your goal "...", fix it, jj squash and git push, run gh pr checks --watch --fail-fast pr-link

Ratatui itself has a lot of much nicer AI generated code in it since then ;)

We've also done a bunch of things to help drive down some of the boilerplate (not all of it mind you - as it's a library, not a framework like other TUI libs)