Squash squash and move

[Brixy]

Coming from git, I am blown away by jj’s sanity and simplicity. Congrats, guys.

I have never thought through the theory of VCSs and just learnt that there is a discussion about the move subcommand in Discord (#2678), so the following is just a -- maybe redundant -- comment from a user’s perspective:

Working with jj, only the move subcommand was not intuitive for me, because I expected it to just move a revision to a different position. But I was looking for a command to squash any revision with another revision.

Would it make sense to support

jj squash --with <WITH>
jj squash --with <WITH> --revision <REVISION>
# or alternatively
jj squash --with <WITH> <REVISION>

and drop the move command for this?

unsquash (and maybe other subcommands) would also be affected.

Sorry if this has already been discussed.

[martinvonz]

I expected it to just move a revision to a different position.

Makes sense. That's exactly what git-branchless's git move does.

Would it make sense to support

jj squash --with <WITH>
jj squash --with <WITH> --revision <REVISION>
# or alternatively
jj squash --with <WITH> <REVISION>

and drop the move command for this?

That sounds reasonable to me. What do others think?

I don't think we want the last version because jj squash and jj move take path arguments as positional arguments. Also, I think I slightly prefer calling --with as --into to make the direction clearer.

[Brixy]

Also, I think I slightly prefer calling --with as --into to make the direction clearer.

Yes, I thought about this, too. This would also make

squash --from <FROM> [--revision <REVISION>]

clearer, if --from is needed/wanted in addition.

[ilyagr]

Squashing squash and move seems like a great idea to me. We had several discussions about what to rename jj move to, and squash seems like a very good option to me. This has the pleasant side-effect that the powerful abilities jj move provides will be easier to discover. I'd still keep amend as an alias.

I like --into, though I'd still keep --to as an alias.

Another thing I'd consider is making this act similarly to diff. jj squash -r abc would squash abc into abc-. jj squash is equivalent to jj squash -r @. jj squash --from abc would squash abc into @. jj squash --into abc would squash @ into abc. Using -r with either --from/--into would be illegal.

We've also been heavily advertising jj move in the docs, so I'd give it a deprecation period with a warning.

[jabolopes]

+1 to jj squash --into.

[Dr-Emann]

I'm pretty strongly against --with and strongly for --into, until I read Martin's comment, I had no idea what jj squash --with <WITH> --revision <REVISION> was intended to mean.

I think this makes a lot of sense to me: I also expected jj move to operate by moving commits around, not moving changes between commits. I think squash naturally makes sense to have that functionality, it makes perfect sense to me that jj squash just defaults to -r @ and --into the parent of the revision specified.

[PhilipMetzger]

I have never thought through the theory of VCSs and just learnt that there is a discussion about the move subcommand in Discord (#2678), so the following is just a -- maybe redundant -- comment from a user’s perspective:

Working with jj, only the move subcommand was not intuitive for me, because I expected it to just move a revision to a different position. But I was looking for a command to squash any revision with another revision.

Would it make sense to support

jj squash --with <WITH>
jj squash --with <WITH> --revision <REVISION>
# or alternatively
jj squash --with <WITH> <REVISION>

and drop the move command for this?

I don't particularly like the idea as jj squash/unsquash/amend are specialized implementations of jj move. Would it help you if the jj movecommand was renamed to jj diffmove, which makes it's intent clear?

Then at some point jj rebase could be aliased or renamed to jj move, which would as you'd expect move a revision to a different position.

[ilyagr]

I just wrote up the opposite suggestion in #2882 (reply in thread). I think it achieves most of your goals, though; in my mind, squash or even amend might be a clearer name than diffmove.

This would leave unsquash in a weird position. I never use it; we could delete it or it could keep doing what it's doing now AFAIC, unless we get a better idea, but I'd rather have people who use it chime in.

[ilyagr]

Another option is to replace the command unsquash with an option to squash, essentially the opposite of the -r option I suggested in the other thread. Not sure what the best name is: jj squash --unsquash? jj squash --opposite-day? UPDATE: I think --unsquash with an alias -u is fine. Update 2: Or perhaps something like --parents-into-children with aliases.

The option would default to @... After a bit of thought, I think it will be less surprising if it's just a boolean option; if you want to unsquash an arbitrary revision, you'd have to write jj squash --unsquash -r abc. --unsquash would be incompatible with --into/--from.

[ilyagr]

Aside: I just realized that jj unsquash/jj squash -u makes sense for merge commits. It would slurp in all the parents. I'm not sure how useful that is, and I'd guess it's not implemented at the moment.

[PhilipMetzger]

I just wrote up the opposite suggestion in #2882 (reply in thread). I think it achieves most of your goals, though; in my mind, squash or even amend might be a clearer name than diffmove.

I am not strongly against renaming jj move to jj squash, I just wanted to bring up the renaming suggestion from the last discussion, which either you or @arxanas suggested. Another thing we have to consider is jj's novelty budget as it is very helpful to new verbs to be differentiated from Git or $FUTURE_VCS.

I think it should be a attainable goal of having just a single command with multiple aliases for squash/unsquash/amend/unamend w/o considering it's name.

[joyously]

I prefer for move to deal with renaming files, like other VCSs.
To me, squash and rebase sound similar, while unsquash and split sound similar. Then, amend is like edit.
Is merge different, or an alias?

[amiryal]

I’ve finally gotten a chance to use jj diffedit in a real-life scenario. I thought initially the command I needed was jj squash -i because I wanted to move one hunk of change from the working copy to its parent commit. In the end, I discovered the following.

All three of these may achieve the same end goal:

• jj squash -i (or jj squash -r R -i if R is not @) (“syntax sugar” shorthand for the next command)
• jj move --to @- -i (or jj move --from R --to R- -i if R is not @)
• jj diffedit --to @- (or jj diffedit --from R --to R- if R is not @)

However, the first two are the same; they start with all the hunks applied and let you subtract hunks from the final result. The last one is different, in that it starts with no hunks applied and lets you selectively add hunks to apply.

To complete the picture with unsquash, the three of these are similarly related to one another:

• jj unsquash -i (or jj unsquash -r R -i if R is not @) (“syntax sugar” shorthand for the next command)
• jj move --from @- -i (or jj move --from R- --to R -i if R is not @)
• jj diffedit --from @- (or jj diffedit --from R- --to R if R is not @)

Seeing this, I wonder if the two commands that need to be consolidated are rather jj diffedit→jj move -i. The outline of my suggestion is thus:

1. Add an option -r R to jj move that is a shortcut for --from R --to R-.
2. Make jj move default to -r @ when no other -r/--from/--to option is provided.
3. Document jj squash as being the equivalent of jj move with fewer options.
4. Add an option --reverse (or suggest a better name for it) to jj move that reverses the meaning of --from and --to. It makes more sense with -r than with --from/--to, so maybe acknowledge that in the documentation as well.
5. Document jj unsquash as being the equivalent of jj move --reverse with fewer options.
6. Add a pair of options --subtractive/--additive (or suggest better names for them) to jj move -i that change the initial state of the interaction (as described above), with the default being --subtractive.
7. Document jj diffedit as being the equivalent of jj move --additive -i.
8. [optional] Document jj move as being the multi-tooled pocketknife that can do everything that the other commands mentioned here can.

WDYT? Should I go ahead and formalise it as a FR?

[ilyagr]

jj move is very different from jj diffedit (and the closely related jj restore) unless you are moving from X to X-. This makes things quite confusing if you consider the case of moving from X to X- first :)

This might need a better explanation in the docs. The point is that jj move --from X --to Y would move the changes (between X and X-) to Y. (Using parentheses instead of grammar :) )

One difference is that jj move can easily create a conflict in Y, whereas restore/diffedit never do. Again, they are only different if Y ≠ X-.

---

There is also a more subtle difference, even in the --from X --to X- case: jj move --from X --to X- will get rid of the commit X and combine its description with that of X- to make the new X-. This is similar to what squash does. So, the idea that squash could be combined with move is still good. I mainly mention this to explain why combining squash and move is a better idea than combining squash and restore or diffedit.

[joyously]

So the --from and --to form a range, not a source and destination? (Asking it that way, it seems obvious, but this is the first I heard of it, and in the context of move those words don't seem like a range.) And -r is a revset, right? I didn't know it could affect multiple.
I still think move should only apply to files, like other VCS.
And I think adding hunks is safer than deleting hunks, when one wants to abort from the editor.

[martinvonz]

This was implemented in #3271. Thanks for your suggestion!

[Brixy]

Thank you very much for considering and implementing this, @martinvonz!