FR: `jj resolve` should affirmatively report whether conflicts in the parent were resolved

[davidbarsky]

Is your feature request related to a problem? Please describe.
When using jj resolve, I'd find it to be extremely helpful if jj resolve affirmatively reported whether all conflicts in the parent commit were resolved. Today, it only reports whether there are any remaining conflicts, which leads me to second-guess myself and run jj st.

Describe the solution you'd like
jj resolve should print additional context about the working copy's conflict resolution state. For example, if a jj resolve command completes successfully and no more conflicts remain, jj resolve should write "Conflict in parent commit has been resolved in working copy" as jj status does.

Describe alternatives you've considered

• I currently run run jj st after a jj resolve, which works, but it's an additional command.
• I could probably setup my shell prompt to report on any remaining conflicts, but I'm lazy and forgot to do a similar integration with Sapling. I'll probably do this after I'm done writing this issue.
• A richer GUI integration with jj could probably also report this state to me, but I haven't bothered using any yet.

Additional context

A screenshot of a successful `jj resolve --tool vscode` and a `jj st` that ran immediately after which reports "Conflict in parent commit has been resolved in working copy".

[arxanas]

If the working copy commit has conflicts (both generally and including the case of the jj resolve output), does it say (conflict) in the status line, like it does for the parent commit?

[davidbarsky]

Sorry for the delay. What do you mean by “status line”? Which command are you referring to?

[arxanas]

@davidbarsky specifically the "Working copy now at: " / "Working copy:" / "Parent commit:" lines in your screenshots.

[davidbarsky]

@arxanas Ah! Yes, I believe it does, if I'm understanding you correctly (see below). At the risk of emphasizing something already obvious to you, I'd "just" like jj resolve to affirmatively say "all conflicts are fixed" and not rely on me to infer that state through the absence of the normal conflict messages.

[martinvonz]

Maybe #5111 will effectively address this?

[davidbarsky]

It would, yes! I'd also be happy to send a PR that copies this snippet from jj status over to jj resolve, if you'd like!

(Naively, it seems like a small/easy papercut to fix independent of #5111, but I don't know what the threshold y'all have for smaller changes like this.)

[arxanas]

@arxanas Ah! Yes, I believe it does, if I'm understanding you correctly (see below). At the risk of emphasizing something already obvious to you, I'd "just" like jj resolve to affirmatively say "all conflicts are fixed" and not rely on me to infer that state through the absence of the normal conflict messages.

Thanks, I just didn't know about whether it showed the information that I thought it showed. (I think I typically don't use jj resolve and instead just open files in the editor and rely on the auto-resolving behavior.)

• Personally: Seeing the presence of (conflict) in the parent commit message and the absence of it in the working-copy commit is enough to rest assured that all conflicts have been resolved.
• Generally: It seems like it could be useful to print a summary of how many conflicts were resolved as a result of the jj resolve operation and how many remained as a result of the resolution, for which the transition from "conflicted parent commit" to "non-conflicted working-copy commit" would be a special case. This could give you a sense of how much progress you had made towards resolving conflicts.
• For now: I wouldn't be opposed to including the same jj status message you linked in the jj resolve output (either by copying it or abstracting it somehow).

Originally, I was just asking my question to understand the jj resolve UI and workflow better, and not because I had any specific recommendation about this issue. I'll defer to @martinvonz or others about the best design or implementation.

[martinvonz]

I agree with all @arxanas said. It might be best to wait for #5111 to land before adding the message to make sure it makes sense. Maybe it will mention the number of resolved conflicts too, as @arxanas said.