Can I move changes from the obslog to a different changeset?

[landtuna]

If I look at jj obslog and see that all the work I did in the most recent commit really belongs in the next change, can I move everything from that commit without choosing by file or doing an interactive move?

[landtuna]

I think I figured it out. I made a new change on top of the commit that I wanted as the parent and then moved from the change that had my new work to the newly-created commit.

[martinvonz]

For future reference, there's an entry about this in the FAQ: https://martinvonz.github.io/jj/v0.15.1/FAQ/#i-accidentally-changed-files-in-the-wrong-commit-how-do-i-move-the-recent-changes-into-another-commit

[landtuna]

Ha, thanks, @martinvonz ! I've even read and used that entry before. Somehow, I forgot about it. It would be nice if jj move could be used like jj move --from commit_id --to changeset_id. But I guess that might get in the way of the use case where you have an ambiguous changeset ID and no other way to refer to it than the tipmost commit ID.

[martinvonz]

That wouldn't work in this case because the diffs that jj obslog -p shows are not between a commit and it's parent, but between a commit and an earlier version of the commit (use jj show <commit id> of a commit in the obslog to see the diff against its parent(s)). We could still have some command for applying an arbitrary diff into a commit, if that's a common enough request.

PS. We just deprecated jj move in favor of jj squash (which now has --from and --into).

[landtuna]

Yeah, I saw that discussion - it's a bit disappointing. squash is one of those terms that carries meaning for git people. I could understand always calling it squash if you're collapsing multiple changes into one change, but it's an awkward term if the use case is moving changes around. The git people are getting their way here with their complaint that move means revision movement, which wasn't even a common thing before git people went all gung-ho about rewriting history. Calling it move-changes or something would avoid overloading squash for non-squashing operations.

[martinvonz]

I actually don't think we're going to use move for moving commits around; I think we're going to use it for marking files as moved (as an alias for mv, perhaps).