Add a "squash" action to `jj arrange` by martinvonz · Pull Request #9037 · jj-vcs/jj

martinvonz · 2026-03-06T07:49:18Z

Checklist

If applicable:

I have updated CHANGELOG.md
I have updated the documentation (README.md, docs/, demos/)
I have updated the config schema (cli/src/config-schema.json)
I have added/updated tests to cover my changes
I fully understand the code that I am submitting (what it does,
how it works, how it's organized), including any code drafted by AI
For any prose generated by AI, I have proof-read and copy-edited with an
eye towards deleting anything that is irrelevant, clarifying anything that
is confusing, and adding details that are relevant. This includes, for
example, commit descriptions, PR descriptions, and code comments.

josephlou5 · 2026-03-06T14:29:14Z

Not to be the naming guy again, but would "squash" make more sense for this action? I have no idea what "fixup" means without reading a description, and "squash" already exists in jj concepts.

martinvonz · 2026-03-06T15:54:48Z

Not to be the naming guy again, but would "squash" make more sense for this action?

Maybe. jj squash does not discard the description by default. This new "fixup" action is like jj squash --use-destination-message. I hope we'll soon have a version of this action that doesn't discard the source's description. If we call this one "squash", then what do we call the one that squashes and lets you edit the combined message?

joyously · 2026-03-06T16:16:16Z

If we call this one "squash", then what do we call the one that squashes and lets you edit the combined message?

Name the action for the action it does, not the flags you give it.

martinvonz · 2026-03-06T16:39:33Z

Name the action for the action it does, not the flags you give it.

I agree and I've tried. I thought "squash, discarding message" was too long. It should ideally not use a lot of horizontal space. Any suggestions?

joyously · 2026-03-06T17:13:11Z

I thought "squash, discarding message" was too long. It should ideally not use a lot of horizontal space. Any suggestions?

Perhaps this is an indication to adjust the UI, by putting the "flags" as toggles, separate from the action name, instead of having separate actions. Or prompt for what to do with the description.

josephlou5 · 2026-03-06T17:28:13Z

I hope we'll soon have a version of this action that doesn't discard the source's description.

That makes sense. Are you imagining something similar to jj squash with no flags that brings up a description editor? Or would it either be "use destination message" or "use source message"?

If we call this one "squash", then what do we call the one that squashes and lets you edit the combined message?

Throwing this out there, but I'm not sure it's a good idea either: "squash changes only" vs. "squash" (which would resolve the description somehow)?

by putting the "flags" as toggles, separate from the action name, instead of having separate actions

This is a good point. I'm not sure if you had any thoughts on what this would look like in the future, i.e., if there would be a way to pass flags to equivalent jj commands, for instance. Or maybe that's too complicated.

martinvonz · 2026-03-06T17:32:51Z

Are you imagining something similar to jj squash with no flags that brings up a description editor?

Yes.

(I don't have much opinion about the other questions yet.)

nolith · 2026-03-07T07:02:33Z

As a non native speaker it took me some time to figure out that "fixup" is a git jargon and not an English word.

If I didn't knew git, I would probably express the fixup concept with one of those words: fold, or absorb.

I like fold the most, because absorb is already a jj concept and may cause confusion.

aaronmallen · 2026-03-07T13:42:54Z

Squish?

joyously · 2026-03-07T14:34:23Z

As a non native speaker it took me some time to figure out that "fixup" is a git jargon and not an English word.

I had the opposite problem.... I am a native English speaker, but don't use Git much, so "fixup" is simply a vague non-word that tells me nothing.
Your idea of "fold" is good, but I still maintain that the flags should be modifiers of known actions instead of new actions. Adverbs, not verbs.

barries · 2026-03-07T16:13:05Z

Food for thought: assuming that the user is thinking first/primarily about the change they're squashing and the destination change is second/secondary in their mind, use option names that implicity refer to the src unless the dest is required.

jj squash ...                  # msg editor
jj squash ... --edit           # msg editor
jj squash ... --discard-msg    # src's msg is discarded, add `--edit` to revise.
jj squash ... --overwrite-msg  # src's msg replaces dest's, add `--edit` to revise.
jj squash ... --merge-msgs     # Use an external tool to merge msgs (thinking an LLM, but user defined), then msg editor. add `--no-edit` (spelling?) to _not_ edit & YOLO the result.

PhilipMetzger · 2026-03-07T19:12:24Z

I currently really like the fold suggestion. If we had an option for squash for preserving the squashed commits message, we'd ideally mirror it here.

martinvonz · 2026-03-08T20:31:06Z

IIUC, we have some people who prefer calling the current "squash and discard description" just "squash" for now and then deciding what to do with "squash and combine descriptions" later (maybe a different name, maybe some other indication in the UI). So I'll go ahead and just replace "fixup" by "squash" now so this hopefully gets unblocked.

martinvonz · 2026-03-08T21:13:09Z

I have renamed it to "squash". This is now ready for review

josephlou5

Also update the PR title.

cli/src/commands/arrange.rs

CHANGELOG.md

I'm about to add support for a "squash" action (name might change). It will be allowed to mark a chain of commits as squashed, but it won'tx be allowed to mark merge commits as fixups. It would be easy to make pressing 'f' a no-op while on a merge commit, but then the user would still mark it as a fixup and later swap the commit with a merge commit. It gets complicated to check all interactions for each action, so this patch instead applies the state update to a clone of the state object, then validates the new state, and discards the new state if it's invalid. For now, the validation always passes.

This will reduce the risk of updating the old state instead of the new state.

It's easier to support squashing while discarding the message then asking the user for the combined message, so that's why I'm adding that first. For reference, `git rebase -i` calls this "fixup" while `hg histedit` calls it "roll". We'll have to decide later how to handle squashing while combining the message.

martinvonz

Thanks for reviewing

cli/src/commands/arrange.rs

CHANGELOG.md

josephlou5 · 2026-03-09T00:36:37Z

LGTM, but also update the PR title.

martinvonz · 2026-03-09T02:18:58Z

LGTM, but also update the PR title.

Done. Sorry, I misread your previous request a "Also updated the PR title.". I thought you had already updated it and I didn't even check :)

yuja · 2026-03-09T12:08:29Z

cli/src/commands/arrange.rs

+                    if let Some(new_tree) = new_tree {
+                        let new_commit = rewriter.reparent().set_tree(new_tree).write().await?;
+                        rewritten_commits.insert(id, new_commit);
+                    } else if rewriter.parents_changed() {


Perhaps, we need to set predecessors somewhere in this function.

yuja · 2026-03-09T12:10:36Z

cli/src/commands/arrange.rs

+        if new_parent_ids != rewrite.new_parents {
+            let store = mut_repo.store().clone();
+            let new_parents = try_join_all(
+                new_parent_ids
+                    .iter()
+                    .map(async |id| store.get_commit_async(id).await),
+            )
+            .await?;
+            let new_base_tree = merge_commit_trees_no_resolve_without_repo(
+                mut_repo.store(),
+                mut_repo.index(),
+                &new_parents,
+            )
+            .await?;
+            tree_terms.push((
+                new_base_tree,
+                format!(
+                    "{} (new parents of squashed commits)",
+                    conflict_label_for_commits(&new_parents)
+                ),
+            ));
+            tree_terms.push((
+                rewrite.old_commit.parent_tree(mut_repo).await?,
+                format!(
+                    "{} (old parents of squashed commit)",
+                    conflict_label_for_commits(&rewrite.old_commit.parents().await?)
+                ),
+            ));
+        }


Can you add test that would fail without these rebasing terms? It would be nicer if we can extract/reuse jj-lib function.

yuja · 2026-03-09T12:12:59Z

cli/src/commands/arrange.rs


    fn is_valid(&self) -> bool {
+        for (id, commit_state) in &self.commits {
+            if self.external_children.contains(id) || self.external_parents.contains(id) {


nit: since external children are included in the rewrite plan, I think we should also validate them.

martinvonz requested a review from a team as a code owner March 6, 2026 07:49

martinvonz force-pushed the mz/splwzttzvowt branch from 7e0f973 to 238b8ca Compare March 6, 2026 07:52

martinvonz force-pushed the mz/splwzttzvowt branch from 238b8ca to abf4fd6 Compare March 8, 2026 21:12

martinvonz force-pushed the mz/splwzttzvowt branch from abf4fd6 to 595b591 Compare March 8, 2026 21:38

josephlou5 reviewed Mar 8, 2026

View reviewed changes

martinvonz added 3 commits March 8, 2026 17:22

arrange: extract function for updating UI state from key event

426c7c7

This will reduce the risk of updating the old state instead of the new state.

martinvonz commented Mar 9, 2026

View reviewed changes

martinvonz force-pushed the mz/splwzttzvowt branch from 595b591 to 832054a Compare March 9, 2026 00:22

martinvonz changed the title ~~Add a "fixup" action to jj arrange~~ Add a "squash" action to jj arrange Mar 9, 2026

yuja reviewed Mar 9, 2026

View reviewed changes

Conversation

martinvonz commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

josephlou5 commented Mar 6, 2026

Uh oh!

martinvonz commented Mar 6, 2026

Uh oh!

joyously commented Mar 6, 2026

Uh oh!

martinvonz commented Mar 6, 2026

Uh oh!

joyously commented Mar 6, 2026

Uh oh!

josephlou5 commented Mar 6, 2026

Uh oh!

martinvonz commented Mar 6, 2026

Uh oh!

nolith commented Mar 7, 2026

Uh oh!

aaronmallen commented Mar 7, 2026

Uh oh!

joyously commented Mar 7, 2026

Uh oh!

barries commented Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PhilipMetzger commented Mar 7, 2026

Uh oh!

martinvonz commented Mar 8, 2026

Uh oh!

martinvonz commented Mar 8, 2026

Uh oh!

josephlou5 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

martinvonz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josephlou5 commented Mar 9, 2026

Uh oh!

martinvonz commented Mar 9, 2026

Uh oh!

yuja Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

yuja Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

yuja Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

martinvonz commented Mar 6, 2026 •

edited

Loading

barries commented Mar 7, 2026 •

edited

Loading