The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.

> I am interested in how to do this with jj

`jj split -r <commit>`, where `<commit>` may be the working copy commit (which is the default). See https://github.com/martinvonz/jj/blob/main/docs/git-comparis... for more examples.

so just for understanding: repeated `git add -p` followed by a `git commit` turns into repeated `jj split; jj squash`, since you create a commit each time?

That would work, yes, but there's also `jj squash -i` to move part of the child commit into the parent. There's also the more generic `jj move` command for moving part of any commit into any other commit (ancestor, descendant, sibling), so you `jj squash -i` is equivalent to `jj move -i --from @ --to @-` (where `@` is syntax for the working copy commit and `@-` is syntax for its parents).

I prefer "git stash -p" to exclude unfinished changes, because if I build up a partial commit in the index there’s no way to test it.

I do that later. I do `git rebase -i` and add `exec` lines to build each commit that must build.

> You do that with a sequence of "git add -p" and "git commit" commands.

You can do that with git commit -p.

True but there's usually a "git diff --staged" in the middle to check what I am committing.

You can do that with “git show HEAD” (and “git commit --amend -p”).

`git diff --staged` is superior. For one, you get all the options to `git diff`. For another, it has no side effects, unlike `git commit --amend -p`.

> `git diff --staged` is superior. For one, you get all the options to `git diff`.

Most of which you can get on git show at least if they're relevant to “what have I added”. And of course you can also use git diff on commits if you need something super specific.

> For another, it has no side effects, unlike `git commit --amend -p`.

… “git commit --amend -p” is the replacement for subsequent “git add -p”, as the GP was talking about a workfliw where they’d intersperse staging stuff and looking at what they’d staged.

Exactly!

`git add -e` is infinitely better.

Try git-crecord.

Yes, I do. I often do this (usually in detached HEAD mode!):

  : ; $EDITOR some-file ...
  : ; $build
  : ; git add -e # take a few chunks, maybe change them
  : ; git diff --staged; git status -uno
  : ; # lather, rinse, repeat
  : ; git commit -m '...' -ev
  : ; 
  : ; git status -uno; git diff
  : ; git add -e # ..
  : ; # lather, rinse, repeat until happy
  : ; 
  : ; git fetch origin
  : ; git rebase origin/master
  : ; # fix any conflicts
  : ; 
  : ; # continue until all bug fix / feature
  : ; # activity for this issue is complete
  : ;
  : ; # review my changes:
  : ; git log --patch origin/master..
  : ;
  : ; # if I have to clean my history a bit:
  : ; git rebase -i origin/master
  : ; # re-order commits, `edit` commits, `drop`
  : ; # commits as needed
  : ; $build
  : ; # fix remaining issues...
  : ; 
  : ; # finally ready to push:
  : ; git push myclone HEAD:refs/heads/this-thing
  : ; 
  : ; # open a PR

Repeat as needed to deal with code review comments until done and integrated.

Are you human?

> detached HEAD mode

Ah, I see, not anymore...

Lol, have an upvote!