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
Option<P> allows us to embed optional argument property in tuple.
let maybe_arg = maybe_pair.map(|pair| parse(...))?;
chain_properties((self, maybe_arg), |_: &(Context, Option<_>)| ...)
For one optional argument, we can instead switch the property functions:
if let Some(pair) = maybe_pair {
let arg = pair.map(|pair| parse(...))?;
chain_properties((self, arg), |_: &(Context, _)| ...)
} else {
chain_properties(self, |_: &Context| ...)
}
If we have various combinations of optional arguments, using Option<P> would
be better.
For stock merge-tools, having name -> args indirection makes sense. For
user-specific settings, it's simpler to set command name and arguments
together.
It might be a bit odd that "name with whitespace" can be parsed differently
depending on the existence of merge-tools."name with whitespace".
This will be used as a parameter of id.shortest*() methods. For now, only
decimal literal is supported, and there's no unary negate operator.
"0"-prefix is disallowed because it looks like an octal number.
I don't think we would want multiple integer types in the template language,
so I chose i64 as the integer type of reasonable width.
A method call with arguments will be combined to (self, args...) tuple.
Unary tuple is useless, but is implemented for consistency.
This tuple_impls! macro is based off the serde one as the Rust core one
requires unstable feature.
