This is one place jj really shines. Using jj new to quickly switch to a new change makes it easier to not drop flow but still break up work. You can come back later and add descriptions or reorder and squash. That way, you don't get into as many situations where splitting a commit is necessary. For those that remain, jj split works well.

▲ idoubtit a day ago | parent | next [-]

Your mileage may vary, because the workflow you described does not suit me. I rarely want to put on hold my commit, work on a new one, then go back later to the former commit.

Most of the time, when working on a new commit I have a few changes related to recent commits. So _when I'm done with all that_, I commit selectively the new work, then dispatch the rest among the other commits:

  git add -p ; git commit
  git add -u ; git absorb

Sometimes, I use `commit --fixup` instead of the automatic `absorb`. Anyway, I tried Jujutsu for a few weeks, some was good and some was bad; it didn't "shine" enough and I went back to pure Git.

▲ minton a day ago | parent | prev [-]

I’ve looked at jj, but couldn’t make sense of the proposed benefits. I always stage individual files and never the entire working directory, so I’m confused how it improves that over git.

▲ ekipan a day ago | parent [-]

I've not tried jj yet so I can only speak to impressions, and those impressions appeal to me a lot. My understanding is that jj amends all the changes in _now_ so there's only one place where changes live: the commit graph. No index, no uncommitted worktree. Just commits. And then jj supposedly gives you a lot more freedom to move through and mutate the commit graph directly, rebasing dependent work for you automatically.

So instead of having to `git add -p` several times to pick apart changes from the worktree, the worktree always goes into the graph and you can `jj split` to pick them apart after.

    jj split # split latest commit into two
    jj edit @- # go back one
    jj describe # change message
    jj split # whoops, insert commit in the middle
    jj edit @+ # move forward again
    $EDITOR myfile # do some changes
    jj st # amend the changes and show status
    jj edit def # jump elsewhere in the graph
    jj squash # put two commits together and auto-rebase its descendants
    jj new abc # start working after latest
    # etc etc

▲

1718627440 5 hours ago | parent | next [-]

In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.

'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.

'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.

'jj describe': 'git commit --amend'

'whoops, insert commit in the middle': just commit

'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).

Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.

Ask, if I glossed over something and shall elaborate.

▲

ekipan a day ago | parent | prev [-]

I confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects.

The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".

Currently I do make use of `git add -p` just like grandparent, but I also feel a psychological burden: I will often leave like 3 or 4 separate 2-line changes in the worktree because I don't wanna bother with the ceremony right now, but my perfectionism also resists me putting a lump commit. That's jj's main appeal to me. It amends my work in, then supposedly let's me sculpt it when I'm ready with less of that ceremony.

	▲	1718627440 5 hours ago \| parent [-]
		JJ and Git seem to have different philosophies, so they cater to different users. I want my VCS to do only things I tell it to, so recording things into the index on its own and automatically rebasing commits are not things I actually want. > I confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects. Have you realized, that Git versions the index yet? It was written by a filesystem guy, who (I think) considers the filesystem to be a shared space, so Git doesn't consider the filesystem to be its playground. Think of "git add" less of preparing things for the next commit and more of telling git that it can consider some state to be part of its world model. Your repository does not consist of everything below a directory (it can actually span across multiple randomly located directories), it does consist of everything that was once added to the repository. > The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise". I do the latter just fine in Git, but yes "git add" is a fundamental part of my workflow. I often add some lines already to the index and start writing the commit message, then trying something again in the working directory and either throwing it away or also adding it, before I finally commit. To me the index is a feature. > but my perfectionism also resists me putting a lump commit Sounds like you will use a VCS correctly. > I don't wanna bother with the ceremony right now I don't know what exactly you consider to be the "ceremony", but I think nearly any git GUI/TUI will let you add lines by selecting with the cursor and pressing a key. The good ones also allow you to edit this. This also works in the opposite way: removing or editing specific lines from an already existing commit. In my experience carefully adding lines results in less mistakes than adding everything and then carefully removing lines, but YMMV.