More detailed description for 'exactly' error?

[HoelzelJon]

Context: I'm trying to write a command-line shortcut where I can type in a unique substring of a change subject, and the shortcut will run jj new for that revision.

I'm writing this as a function in my .zshrc, and I'm calling it jed for "jj edit" since I'm using it to edit a given existing mutable commit (I am aware this somewhat diverges from the terminology used by jj edit). Note that $@ in a zsh function refers to all arguments being passed in (so I can call this function without having to wrap the string in quotes).

I could do it like this:

function jed() {
        jj new -r "exactly(mutable() & mine() & subject(substring-i:\"$@\"), 1)"
}

If this matches more than 1 revision, it prints this error (as expected):

> jed wip
Error: The revset has more than the expected 1 revisions

For my usecase, I'd like to see some further details about which revisions matched the revset, so that I can either:

• explicitly run jj new with an ID of one of the revisions, or
• re-run jed with an appropriately more-specific subject string

I've written this more complex function instead, which runs jj log --count on the same revset to check the count, and then jj log again to list the revisions if the count is >1:

function jed() {
        rev="mutable() & mine() & subject(substring-i:\"$@\")"
        count=(`jj log --count -r "$rev"`)
        if [[ $count == 0 ]] then
                echo "Description matches 0 revsets (expecting 1). Typo?"
        else
                if [[ $count != 1 ]] then
                        echo "Description matches $count revsets (expecting 1):"
                        jj log -r "$rev" -G --no-pager
                        echo "Run 'jj new <rev>' to select one of these, or else use a more specific subject string"
                else
                        jj new -r "$rev"
                fi
        fi
}

I don't expect it's desirable to change the default behavior of exactly to always be more verbose, but I'm curious if it could be possible to add some kind of option for the error message to list all matching revisions?

To be clear, this is not a significant issue, but I was a bit sad when I found that jj can't currently do everything I want here in a nice one-liner (since every other functionality I've thought up so far has been doable that way). I realize this could open a whole can of worms (e.g. what format should be used when printing those revs?), so it's fine with me if this idea doesn't get implemented, if the complexity isn't deemed worth the benefit.

Or maybe there is a simpler way to get what I want already, in which case, please let me know. I expect I could implement this as a JJ alias, but it's not clear to me if that would provide any material simplification compared to this zsh function.

Thanks all!

[joyously]

What do you get on the command line using tab completion, with just your example jj new -r wip<TAB>?

[HoelzelJon]

Tab completion isn't showing anything in that situation. I wasn't aware of the tab completion until now actually, but it seems like it works based on change IDs and bookmarks, but not on descriptions.

To be clear, I have some local commits with a description subject like wip: ..., and those are what I'm matching to in this example.

[joyously]

Since you didn't know about the completions, perhaps you haven't loaded the dynamic completions?

[HoelzelJon]

I tried setting up dynamic completions based on the instructions in the docs, but I'm seeing the same behavior. I think I've already had dynamic completions enabled, since if I set up the "standard" completions and then do jj new -r <TAB>, I get a list of files instead of anything jj-ish.

[PhilipMetzger]

For my usecase, I'd like to see some further details about which revisions matched the revset, so that I can either:

• explicitly run jj new with an ID of one of the revisions, or
• re-run jed with an appropriately more-specific subject string

While this is possible, we currently don't do that because for some backends like Google index accesses are expensive (and finding a solution which scales correctly is hard). This sounds similar to the request of showing all revisions which have the same prefix when the index changes for a previously unambiguous prefix.

I don't expect it's desirable to change the default behavior of exactly to always be more verbose, but I'm curious if it could be possible to add some kind of option for the error message to list all matching revisions?

^, summarized in the answer above.