Ways to split a merge commit and jj unsquash

[ilyagr]

I'd like to have a way to prevent jj unsquash from abandoning empty commit, especially if it's a merge commit

The situation I'm in is that I have a merge commit that resolves a conflict. I wanted to turn it into an "empty" merge commit and a separate commit that does the conflict resolution.

Alternatively, there could be some other easy way to partition a merge commit into an empty merge and another commit for conflict resolution (or fixing whatever logical conflicts the merge creates). I'm not aware of one.

[martinvonz]

Alternatively, there could be some other easy way to partition a merge commit into an empty merge and another commit for conflict resolution (or fixing whatever logical conflicts the merge creates). I'm not aware of one.

This discussion's title is actually a good hint about one way: use jj split. Since you want the first commit to be empty, you can make it empty in you diff-editing tool (e.g. Meld), or you can do jj split non-existent to to say pick no changes for the first commit (assuming non-existent isn't a path in your repo, of course).

Another solution is to create a new merge commit and rebase the resolution on top. Note that you can rebase the existing conflict resolution using jj rebase -r <old merge commit> -d <new merge commit>. By the way, for creating the new merge commit, a generic solution to #571 would be nice, so you could do jj new/merge A-, where A is the old merge commit.

[ilyagr]

I did end up using jj split. It took quite a bit of work, since:

1. I didn't think of the jj split non-existent trick.
2. I assumed it wouldn't leave an empty commit like unsquash. So, I created a temporary file. (At this point, it would have helped if jj unsquash supported getting a list of paths or if I realized that jj split does take paths).
3. It wasn't clear if I'm supposed to copy over all the changes I care about from left pane to right pane, or if I'm only supposed to move the changes I didn't care about.

A better non-interactive jj split could solve it. E.g., we could have jj split --empty-parent and jj split --empty-child to create an empty parent or an empty child. Alternative names could be jj split --none and jj split --all.

[ilyagr]

Also, thanks! I'm just trying to record pain points I run into and think out loud about what to do with them.

[martinvonz]

1. I didn't think of the jj split non-existent trick.

FWIW, I agree that it's just a hack. It would even be reasonable for it to fail instead (with something like "Error: 'non-existent' doesn't exist in abc123").

2. I assumed it wouldn't leave an empty commit like unsquash. So, I created a temporary file. (At this point, it would have helped if jj unsquash supported getting a list of paths or if I realized that jj split does take paths).

As a user, I think I would be confused if split created an empty commit and that was immediately removed.

I agree that unsquash should support paths.

3. It wasn't clear if I'm supposed to copy over all the changes I care about from left pane to right pane, or if I'm only supposed to move the changes I didn't care about.

Just to make sure, did you notice the JJ-INSTRUCTIONS file? That file includes "Adjust the right side until it shows the contents you want for the first commit." I'm happy to take patches to clarify that if necessary.

A better non-interactive jj split could solve it. E.g., we could have jj split --empty-parent and jj split --empty-child to create an empty parent or an empty child. Alternative names could be jj split --none and jj split --all.

When you described what you wanted to do, I thought of it as "insert a commit before the current merge commit"; I think I didn't realize that jj split would also make sense until I looked again at the title. What do you think about the jj new A- && jj rebase -s A -d @ solution? That would leave you with the new merge commit as the working-copy commit, so you might want an additional jj new at the end, however.

jj split --empty-child is very close to jj new, right? I doubt I'd ever reach for that option. I can see having it for consistency, however.

[ilyagr]

As a user, I think I would be confused if split created an empty commit and that was immediately removed.

I agree, but there is currently little consistency. Another thing that happens is that, if a commit changes only one file afile, jj split afile does not create a new commit currently. My expectations were also confused by the behavior of squash and unsquash.

I agree that unsquash should support paths.

👍 I'll turn this into an issue or a PR at some point unless you beat me to it.

Just to make sure, did you notice the JJ-INSTRUCTIONS file?

I did. At the time, I think I was confused by whether the "first" commit is going to be the parent or the child. Thinking about it now, only one of these makes sense, but perhaps changing JJ-INSTRUCTIONS to say first (parent) commit would help.

What do you think about the jj new A- && jj rebase -s A -d @ solution?

It's a good solution. I thought of it vaguely, but I didn't expect jj new A- to work because of #571 and because I can never remember which commands take revisions as an -r argument and which take them directly.

[martinvonz]

As a user, I think I would be confused if split created an empty commit and that was immediately removed.

I agree, but there is currently little consistency. Another thing that happens is that, if a commit changes only one file afile, jj split afile does not create a new commit currently. My expectations were also confused by the behavior of squash and unsquash.

That jj split afile case you mentioned is because of this: https://github.com/martinvonz/jj/blob/6526b76ef083be9a04162d7ce09e4206dc13b289/src/commands.rs#L2985

I don't know if we should remove that check or if using jj split <all files in a change> to insert a new, empty commit in a stack is not the best way to achieve that. Maybe we should have another command for inserting an empty commit instead, if that's a common-enough usecase.

I agree that unsquash should support paths.

👍 I'll turn this into an issue or a PR at some point unless you beat me to it.

Sounds good! I'll probably not beat you to it. If you start working on that, maybe this spreadsheet showing some of the current inconsistencies is useful.

Just to make sure, did you notice the JJ-INSTRUCTIONS file?

I did. At the time, I think I was confused by whether the "first" commit is going to be the parent or the child. Thinking about it now, only one of these makes sense, but perhaps changing JJ-INSTRUCTIONS to say first (parent) commit would help.

Sure, that's an easy fix. I'll send a PR.

What do you think about the jj new A- && jj rebase -s A -d @ solution?

It's a good solution. I thought of it vaguely, but I didn't expect jj new A- to work because of #571

Yes, that doesn't currently work, but you can manually pass each revision as an argument.

and because I can never remember which commands take revisions as an -r argument and which take them directly.

FYI, the reasoning is that commands that take paths as arguments take those as positional arguments and therefore need -r for revisions. Since PR #569, you can use -r even for jj new etc.