FR: Allow file show to accept multiple revisions

[stefanboca]

Is your feature request related to a problem? Please describe.
I'm trying to write a neovim plugin for previewing diff hunks, similar to what https://github.com/lewis6991/gitsigns.nvim does for git. I need to get an unmodified version of the current file to compare the current buffer to in order to determine the changed lines. file show -r @- usually works, unless the working copy commit has multiple parents.

Describe the solution you'd like
file show accepts multiple revisions, so something like jj file show -r 'all:@-' <path> is possible

Describe alternatives you've considered
jj --config-toml 'ui.diff.tool = ["cat", "$left/<path>"]' diff -r @ <path>
This works for merge commits, but not when the file at is unchanged for the current revision, because the file at isn't copied into $left.
I could work around this using file list to decide when to use the current working copy version of the file as the diff base, but this gets complicated mainly because I'm running everything with --ignore-working-copy (for performance and to avoid polluting the oplog with snapshots) so the latest snapshot isn't always up to date.

[ilyagr]

In other words, you'd like jj file show -r all:@- to show the file as it would be if you did jj new @-? That makes sense to me. Requiring all: here also makes sense to me.

[martinvonz]

There's the more general issue of how to refer to the auto-merged parents of a commit. It bothers me that jj diff -r X cannot be expressed using jj diff --from --to. But I don't have a good answer to that. You could say that --from and --to should actually resolve to trees, just like Git does. Then we could say that a revset with multiple commits refers to the merge of the commit, or we could define some other way of saying how to produce a tree given a revset.

One argument against that is that it's not worth the complexity. Another is that it might make copy tracing harder if we don't have a source and destination commit to trace copies between.

[ilyagr]

We could try to more generally support something like automerge:X, by analogy with all:X. (Perhaps we can come up with a shorter name, but it's also not the most common thing to do).

If we had that, we'd probably want to disallow jj file show -r all:X in favor of automerge, but I don't think either feature should block the other.

This wouldn't allow performing revset functions on the automerge. I'm not sure whether this is ever desirable.