	▲	shermantanktop 9 hours ago
		This is me! I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion. Hence I have multiple workspaces, and I shelve changes a lot (IntelliJ. I end up with dirty repos too and that can be painful to cherry-pick from. Sometimes I just create a git patch so I can squirrel the diffs into a tmp file while I cleanup the commit candidate. I often let changes sit for several days while I work on something else so that I can come back and decide if it’s actually right. It’s chaotic and I hide all this from coworkers in a bid to seem just a bit more professional. I admire people who are very deliberate and plan ahead. But I need to get the code under my fingers before I have conviction about it.
	▲	sfink 7 hours ago \| parent \| next [-]
		I'm about the same. jj is kind of perfect for that. Example: # I've finished something significant! Carve it out from the working "change" as its own commit. `jj commit --interactive` # aka `jj commit -i` or `jj split`, depending on how you prefer to think of it: making a commit for some work, or splitting a separate commit out of the working change. # Oops, missed a piece. `jj squash --interactive` # aka `jj squash -i` # Let me look at what's left. `jj diff` # Oh right, I had started working on something else. I could just leave it in the working change, but let me separate it out into its own commit even though it's unfinished, since I can always add pieces to it later. `jj commit -i` # Wait, no, I kind of want it to come before that thing I finished up. Shoot, I messed up. `jj undo` # Let me try that again, this time putting it underneath. `jj split -B @-` # aka `jj split --insert-before @-`. @ is the working change, @- is its immediate parent(s), @-- is all grandparents, etc. # Note that instead of undoing and re-selecting the parts, you could also `jj rebase -r @- -B @--` to reorder. And in practice, you'll often be doing `jj log` to see what things are and using their change ids instead of things like `@--`. # I also have some logging code I don't need anymore. Let me discard it. `jj diffedit` # Do some more work. I have some additions to that part I thought was done. `jj squash -i` # And some additions to that other part. `jj squash -i --into @--` # etc. There's a lot more that you could do, but once you internalize the ideas that (1) everything is a commit, and (2) commits (and changes) can have multiple parents thus form a DAG, then almost everything else you want to do becomes an obvious application of a small handful of core commands. Note: to figure out how to use the built-in diff viewer, you'll need to hover over the menu with the mouse, but you really just need f for fold/unfold and j/k for movement, then space for toggle.
	▲	chriswarbo 8 hours ago \| parent \| prev [-]
		> I often find that in the process of making one change, I have also made several other changes, and only recognize that they are distinct after following the ideas to their natural conclusion. I do that all the time. With git, everything starts "unstaged", so I'd use magit to selectively stage some parts and turn those into a sequence of commits, one on top of another. With jj I'd do it "backwards": everything starts off committed (with no commit message), so I'd open the diff (`D` in majutsu), selecting some parts and "split" (`S` in majutsu) to put those into a new commit underneath the remaining changes. Once the different changes are split into separate commits, I'd give each a relevant commit message.