There's a subtle difference between
- 'expression = { whitespace* ... whitespace* }', and
- '_{ whitespace* ~ expression ~ whitespace* }'.
The former includes surrounding whitespace in an "expression", the latter
doesn't. This affects the span of error indication.
The added expect_arguments() is basically a copy from the template_parser.
I'll reimplement it to support keyword arguments, so I don't care much about
the current implementation.
I leave expect_no/one_argument() as wrappers because parsing 0/1 arguments
is pretty common.
Error messages are slightly changed. I personally prefer not to add extra
code for singular/plural handling, but if we do, I'll add 'if N == 1' case.
Our internal backend at Google uses a 32-byte change id, so I'd like
to make the backend able to decide the length. To start with, let's
make the backend able to decide what the root change id should
be. That's consistent with how we already let the backend decide what
the root commit id should be.
The function is currently only about the length of commit IDs, so
let's clarify that. I'm going to add another function for the length
of change IDs next. I don't know if we're going to care about lengths
of other hashes in the future. We might even be able to remove the
current restriction that all commit IDs and all change IDs have the
same length.
The assumption here is temp_dir wouldn't contain invalid utf-8 bytes. If it
can contain invalid bytes, maybe we can remove temp_dir from arguments, and
chdir(temp_dir) instead.
This unblocks the use of Regex. We could use regex::bytes, but it's way
more complex as we would have to go back and forth between str/OsStr and
bytes.
The default edit_args will be changed to ["$left", "$right"] to support
variable substitution without breaking the existing configuration too much.
The default merge_args could also be set if we could come up with something
meaningful.
The unique-prefixe tests are typically the slowest tests. Here's the
end of my `cargo nextest --workspace` output (from an arbitrary run,
not best-of-5 or anything):
PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets
PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled
PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
These tests create 50-100 commits in a loop. I think much of it comes
from the subprocessing and/or the repeated loading of the repository
in the subprocesses. Rewriting them to use `jj duplicate` for creating
many commits at once speeds them up. Here are the timings after:
PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled
PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets
PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
I felt that the config is too narrow to have it's own top-level [diff]
section, and I couldn't think of another good place to have it. I'm
happy to hear other suggestions.
I think the CLI currently checks that the backend is not told to write
a merge commit with the root as one parent, but we should not panic if
those checks fail.
If FullCommandArgs is renamed to CommandNameAndArgs, the meaning of .args()
will get fuzzy. This also clarifies that the name part exists even if the
source command string is empty.
This extracts the more general `resolve_mutliple_nonempty_revsets_flag_guarded`
out of `resolve_base_revs`. This function should be useful for `rebase -s`,
etc.
`resolve_base_revs` is renamed to `resolve_destination_revs`; that's simply a
better name for it. It is also quite specific to the `new` and `rebase -d`
commands. It will be moved out of general utilities in the next commit
