cli: default to log when no subcommand is provided

[elasticdog]

This is a convenience optimization to improve the default user experience, since jj log is a frequently run command. Accessing the help information explicitly still follows normal CLI conventions, and instructions are displayed appropriately if the user happens to make a mistake. Discoverability should not be adversely harmed.

Note that this behavior mirrors what Sapling does, where sl will display the smartlog by default.

If people are onboard with this change, where else would you recommend that the behavior be documented?

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (src/config-schema.json)
• I have added tests to cover my changes

[joyously]

Since the working copy is "committed" at some invocations of jj (unknown to me) but not others, there needs to be consistency.
If there is a status command, that would be preferable to a log, and it should not commit anything.

[martinvonz]

Since the working copy is "committed" at some invocations of jj (unknown to me) but not others

FYI, it's practically all.

there needs to be consistency. If there is a status command, that would be preferable to a log, and it should not commit anything.

It already does that...

[arxanas]

@joyously by the way, it might not be obvious from this PR, but it's changing jj to match Sapling's behavior, where it shows the graph log when you invoke sl without any arguments. This seems to have been a popular UI decision on their part, since patch stack users are constantly viewing the commit graph. (I realize now that this explanation is entirely in the commit message, but Github doesn't make it easy to notice that, so maybe you missed it as well 😅.)

[joyously]

it might not be obvious from this PR, but it's changing jj to match Sapling's behavior, where it shows the graph log when you invoke sl without any arguments.

I sort of got that from the comments.
I was just trying to emphasize that new users would be more likely to not specify a subcommand, and that a plain invocation like that should not affect the repo.
In the sense that no subcommand is given, a status makes more sense than a log, or maybe it should be a combination when neither is specified.

[ilyagr]

One hesitation I have is that I actually find the output of jj without arguments useful. I think it's especially useful for a new user. Potentially, it will become more useful if we can better structure the list of commands.

I find jj help and jj --help a bit too verbose; otherwise they'd be a good alternative.

One option I can think of is to have jj print a hint in addition to the log:

Hint: use `jj -h` for a list of jj's commands. Set `ui.default-command = "log"` config to disable this message.

Another alternative I've been thinking about is encouraging alias "jl=jj log". We could even have jj util shell-setup that includes jj util completion and also sets up this alias. On the other hand, I'm not sure if that is discoverable enough.

Finally, we could look into making jj help work the same as jj -h, and then have jj help --full. I'm not sure whether clap supports that.

---

I don't think these worries have to prevent us from merging this and trying it out, but I thought I'd share them.

[elasticdog]

Okay, I've pushed a new version where the default command is resolved earlier in the process per @martinvonz's suggestion. That did solve the previous limitation of only being able to parse global options, and it will now pass through any options as expected. The behavior can be configured by setting ui.default-command to a string with the desired subcommand name, subcommand alias, or user-defined alias (which can be used if you want multiple arguments to be injected).

The one minor issue I've seen with the approach is that specifying jj -T show won't work where jj log -T show will, as I naively bail on using a default command if any arguments match an existing valid subcommand (jj show, in this case). I'm open to any suggestions for more robust handling, but it's a pretty small edge case.

[martinvonz]

I still think this feature is a bit weird because of the inconsistencies (like the jj -T show case you mentioned).

I also think @ilyagr had a good point about showing the short help to new users, but maybe we can improve that by printing warning (as Ilya said).

[elasticdog]

I came up with a less-naive approach and now check the ArgMatches directly, so I believe all inconsistencies have been removed (jj -T show works, and all previous tests have been restored). Let me know what you think.

[elasticdog]

Related to the preference for short help, it might be possible, but it would take a bit of work. Clap's auto-generated help subcommand actually used to default to short help and users could explicitly override it to prefer the long help...but then, upstream removed the option and forcibly defaulted to long. After that, the ArgActions feature became supported, which might provide a clean way to customize things (see clap-rs/clap#4687). A final resort would be to disable the built-in auto-generated command, but then I think we'd be on the hook to maintain the desired help output ourselves (see: clap-rs/clap#4056).

[elasticdog]

Oh, and I think we can easily print out the above suggested hint if the setting isn't in place. Give me a bit and I'll push that change and tests.

EDIT: done.

[martinvonz]

This looks pretty simple now :) Thanks!