FR: jj commit --insert-{before,after} <change id>

[amiryal]

Effectively, overload jj commit with another atomic shortcut that is already achievable with a series of other commands:

jj commit --message MSG <--insert-before|--insert-after> C

Would become a shortcut for:

jj new --message MSG --insert-after C
# ↑ note the fresh new change id
jj move --to new-change-id

[amiryal]

[As I was writing this comment, I realised my idea is not baked enough. I will possibly raise it again (or not); see final paragraph for the reason.]

Prior discussions

A similar idea had been raised before, in this #1188 (comment) by @gasche (lightly edited excerpts):

My feature proposal: jj move --from foo --insert-{before,after} bar.

Instead of extending jj rebase, the idea is to add to jj move some of the capabilities of jj new. In particular,

jj move --from foo --insert-{before,after} bar other-args

can currently be done as

jj new --insert-{before,after} bar
jj move --from foo other-args
# ... and then go back to whichever chage you were editing

If I read the ensuing discussion correctly, that idea fell short because of semantics and context. The context was of the jj rebase command, which preserves change IDs and doesn’t create new ones. The proposed feature was “to add to jj move some of the capabilities of jj new”, which would change the semantics of move from only moving diffs around to also creating new revisions.

My current proposal focuses on a more narrow use case, when the diff is in the working copy and we want to insert the changes as a new revision somewhere else in the graph.

However, my proposal also falls short on semantics. jj commit also preserves the change ID of the working copy and creates a new empty one, which is not the case for jj new followed by jj move. Closing, but free to discuss further and may reopen in the future.

[gasche]

My high-level understanding is that jj currently lacks tools to move changes around (we can use jj move to move patches, but in a way that does not preserve the intended identity of changes), both commit and rebase only move changes into leaves of the commit graph (places that have no children). So there is some hard work to do if we want more general operations, and this is why the implementation work on suggested git rebase improvements is not progressing quickly. Once that work is done, we will be able to use it to introduce variants of other commands that move changes around.

[joyously]

While I personally don't think that jj should follow Git's concept of two levels of commands, I wonder if moving changes around is really a low-level activity that maybe shouldn't be exposed to the user. It seems to me that the tool should be managing the versions, and history just happens in the order the user does things. The user needn't manage the graph if the tool provides good commands for visualizing the changes and versions.

[gasche]

To me, the "just in the order the users did thing" notion of history corresponds to the operation log. Many version-control users want to be able to exert more control on the change graph, proposing an idealized view of the document evolution that may not correspond to the user's own history. "rewriting history" in this way is a key element of many social practices around software development (for example, change-by-change code review), and helps avoid conflicts or ease their resolution.

Explicit control over the "history" (the graph of changes) is advertised as a core feature of jj, see for example the Comprehensive support for rewriting history subsection of the README.

[joyously]

Explicit control over the "history" (the graph of changes) is advertised as a core feature of jj

Yes, and I wonder if that is what makes it "change management" as opposed to "source code management". In my mind, the tool for "version control" takes the burden of the "control" part away from the user, providing ease with the "version" part.