FR: jj st/status and other movement commands should also list child commit(s) if any exist

[digidoor]

Current functionality is that jj st lists the working copy as well as any parent commits. It seems prudent that it should also list child commits if any exist. This would be very helpful for absent-minded developers and when coming back to work after a substantial break: to be reminded that you are not at a leaf node.

It's also the case that when performing an operation such as jj new -B @, the subsequent output states "Rebased N descendant commits". I think it would make sense to also explicitly list the usual details for all direct children (but not all descendants, as jj st is useful for how concise it is).

But at the very least I believe it only makes sense for jj st to list children as well as parents as default behavior. (Currently it will happily list all parent commits but no child commits.)

[arxanas]

I suppose the main reason to show the parent commit is that one common workflow is to squash changes into the immediate parent? Is there a workflow like that but for merging into a child?

(I'm personally slightly in favor of this FR, but I'm curious to know if there's any concrete workflows it enables.)

[digidoor]

It's not exactly how I would explain my workflow, but compare

https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html

and

https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-edit-workflow.html

The thing with the squash workflow is that it's essentially recreating git's index, but with jj's "every change is already a part of a commit" mechanics there isn't really any need to. jj new --insert-before <rev ID>, jj split, and related tricks to my eye obviate the need for this index-like approach, especially given how quickly anything can be undone with jj undo <op number>, itself super easy since you can sniff around with jj diff -f abc -t abc+ --at-op=<op number> (or abc-, however you want to approach it) as needed.

As an example of where I would want to see child commits would be when traversing a branch to add comments, alter formatting, or making some other such small/safe changes where editing in place makes more sense than the more cautious and compartmentalized approach of squashing in a big change from a new faux-index child (which I don't think is ever really necessary with jj to begin with). Since this is how I'm often working, I've already updated my config.toml to assume editing instead of making new branches when using jj next and jj prev.

[ui.movement]
edit = true

Getting back to the example, I just jj next; jj diff, add comments/documentation, variable/function name changes, repeat until I'm at the leaf of that branch. (I personally see a lot of value in being able to modify things when/where they happened rather than having e.g. a bunch of comments for old code pop in far down the line from where it was introduced, but that's just me.)

So I guess the actual desired feature would be to list both parents and children on any command that changes which node in the commit tree is the working copy, namely jj st, jj next, jj prev, jj split, jj new -B/-A and jj edit (plus whatever others I may be forgetting). The current defaults assume a workflow of working from leaf nodes and squashing in to their parents, but jj enables more fun, flexible, and ad hoc approaches.

Like the ui.movement.edit option I referenced above, this could be implemented as a config option for those of us who aren't into the whole child -> parent squash workflow.

[digidoor]

Oh, and since I don't plan around squashing as my default workflow, I will work in place without using a faux-index child. If I overrun my original commit description, I'll just jj split, and from there either work on the child created by the split, or jj prev and continue working in the parent. With this in mind, parent commits don't have any particular primacy over child commits in terms of where I'm "aiming my work", if that makes sense.