A list type isn't so useful without a map operation, but List<CommitId>
is at least printable. Maybe we can experiment with it to craft a map
operation.
If a map operation is introduced, this keyword might be replaced with
"parents.map(|commit| commit.commit_id)", where parents is of List<Commit>
type, and the .map() method will probably return List<Template>.
The argument order is different from Mercurial's indent() function. I think
indent(prefix, content) is more readable for lengthy content. However,
indent(content, prefix, ...) might be better if we want to add an optional
firstline_prefix argument.
Template functions like indent() or fill() need to manipulate labeled
output. Since indent() is line oriented, it could be implemented as a
post-processing filter. OTOH, fill()/wrap() inserts additional "\n"s. If we
do that as a post process, colorized text could be split into multiple lines,
and would mess up graph log output. By using FormatRecorder, we can apply
text formatting in between labels.
I thought we could disallow text wrapping of labeled template fragments, but
the example in #1043 suggests that we do want to wrap(whole_template_output)
rather than simple description.wrap().
In `git_fetch()`, any glob present in `globs` is an "allow" mark. Using
`&[]` to represent an "allow-all" may be misleading, as it could
indicate that no branch (only the git HEAD) should be fetched.
By using an `Option<&[&str]>`, it is clearer that `None` means that
all branches are fetched.
Using &[String] forces the caller to materalize owned strings if they
have only references, which is costly. Using &[&str] makes it cheap
if the caller owns strings as well.
This eliminates ambiguous parsing between "func()" and "expr ()".
I chose "++" as template concatenation operator in case we want to add
bit-wise negate operator. It's also easier to find/replace than "~".
Here we know each field will never be empty, but separate(" ", foo, bar)
looks slightly better than 'foo ++ " " ++ bar'. Implicit template concatenation
will be disabled soon.
To be able to make e.g. `jj log some/path` perform well on cloud-based
repos, a custom revset engine needs to be able to see the paths to
filter by. That way it is able pass those to a server-side index. This
commit helps with that by effectively converting `jj log -r foo
some/path` into `jj log -r 'foo & file(some/path)'`.
Since there's no easy API to snapshot the stale working copy without releasing
the lock, we have to compare the tree ids after reacquiring the lock. We could
instead manually snapshot and rebase the working-copy commit, but that would
require more copy-paste codes.
Closes#1310
I plan to make `RepoLoader::init()` return a `Result`, which means
that `WorkspaceLoader::load()` will need to return more kinds of
errors. Making it return `WorkspaceLoadError` is a good start. By also
extracting a function for converting `WorkspaceLoadError` to
`CommandError`, we can reuse a the handling of `PathError` in
`cli_util`.
So the caller can print a commit summary.
It's getting less clear why cli_util::update_working_copy() takes a repo
argument. It might be better to extract a helper struct that operates on
repo + workspace (minus CLI stuff), and move it to the lib crate.
The outermost "op-log" label isn't moved to the default template. I think
it belongs to the command's formatter rather than the template.
Old bikeshedding items:
- "current_head", "is_head", or "is_head_op"
=> renamed to "current_operation"
- "templates.op-log" vs "templates.op_log" (the whole template is labeled
as "op-log")
=> renamed to "op_log"
- "template-aliases.'format_operation_duration(time_range)'"
=> renamed to 'format_time_range(time_range)'
The type doesn't seem to provide any benefit. I don't think I had a
good reason for creating it in the first place; it was probably just
unfamiliarity with Rust.
I was thinking of replacing `RevsetIterator` by a regular
`Iterator<Item=IndexEntry>`. However, that would make it easier to
pass in an iterator that produces revisions in a non-topological order
into `RevsetGraphIterator`, which would produce unexpected results (it
would result in nodes that are not connected to their parents, if
their parents had already been emitted). I think it makes sense to
instead pass in a revset into `RevsetGraphIterator`.
Incidentally, it will also be useful to have the full revset available
in `RevsetGraphIterator` if we rewrite the algorithm to be more
similar to Mercurial's and Sapling's algorithm, which involves asking
the revset if it contains parent revisions.
This basically undoes d6c6cdb45c "templater: store type-erased version of
commit/change id." Since they are looked up differently, they should preserve
the original types.
FWIW, I'm thinking of making the repo parameter generic over Arc<ReadonlyRepo>
and &MutableRepo. It will allow us cache a parsed commit_summary template.
Now it's ready to split template_parser/templater into base template functions
and "commit" templater. I think Signature and Timestamp are basic types, so
they aren't moved to CommitTemplatePropertyKind. Perhaps, a duration type from
OpTemplate will also be added to CoreTemplatePropertyKind.
The idea is that a derived language will do wrap_<core_type>() as
DerivedProperty::Core(CoreProperty::<Type>(property)). This could be dealt
with some From<CoreProperty> trait impls, but the resulting code looked
a mess, and compile errors would be cryptic. I think this is somewhat similar
to serde::Serializer API.
I also rejected the idea of abstracting property types over Box<dyn>. Maybe
it's okay for method dispatching and extraction of some basic types, but it
wouldn't work if we want to implement comparison operators for any compatible
types.
wrap_commit_or_change_id() and wrap_shortest_id_prefix() will be moved to
the CommitTemplateLanguage. I'll add impl_wrap_fns() macro after splitting
the modules.
The "core" template parser wouldn't know how to dispatch property of types
added by a derived language. For example, CommitOrChangeId/ShortestIdPrefix
will be moved to the "commit" templater.
This trait will provide ways to dispatch keyword/method nodes, and wrap
TemplateProperty object with a dedicated "Property" enum.
build_keyword() and context parameter "I"/"C" have been migrated to it.
This is just a little preparation for extracting a `Repo` trait that's
implemented by both `ReadonlyRepo` and `MutableRepo`. The `index()`
function in that trait will of course have to return the same type in
both implementations, and that type will be `&dyn Index`.
It turned out bad idea because EPIPE (or SIGPIPE) is kind of a successful
termination. We could show some warning based on pager exit code, but let's
avoid messing up again.
io::Error occurred in handle_command_result() is still mapped to a BrokenPipe.
panic()-ing there should be wrong.
`jj log | head` consistently prints "Error: Broken pipe" for me. I
don't know how the output gets printed after the pipe has been closed,
but neither `git` nor `hg` prints an error, so I think we shouldn't
either.
Thanks to 81af5f820b "repo: calculate shortest unique prefix separately for
commit/change", commit_id.shortest() now works even if the repo is MutableRepo.
No more format!() template expressions.
We might want a separate namespace for configurable "default" aliases, but
let's start with a simple approach. Even if we had [default-templates]
section, it would be practically the same as [template-aliases] so long as
'default-templates.f()' appears as 'f()' in template.
Even though we don't know the details yet, we know that we want to
make the index pluggable like the commit and opstore
backends. Defining a trait for it should be a good step. We can refine
the trait later.
Since type/name checking is made after alias substitution, we need to preserve
the original context to generate a readable error message.
We could instead attach a stack of (alias_id, span) to ExpressionNode, but
the extra AliasExpanded node helps to capture downstream error by a single
.map_err() call.
This is basically a copy of revset::RevsetAliasesMap. We could extract a
common table struct, but that wouldn't be worth the effort since the core
alias substitution logic can't be easily abstracted.
I'll add an alias table there. Since this function borrows self, it can't
always be used in between mutable operations. For log-like commands, this
should just work fine.
This prepares for template aliases support #1190. Unlike revset, template
expressions can be of various types, whereas alias substitution will process
untyped nodes. That's one reason that ExpressionNode is closer to parsed tree
than evaluatable Property structs. Another reason is that it's uneasy to split
name/type checking into "parsing" and "building property function" stages.
We could do alias expansion at once while building Property functions, but
that would make testing harder because Property isn't Debug + PartialEq.
I'm going to split 'parse() -> Expression' functions into 'parse() -> AST'
and 'build(AST) -> Expression'. The duplicated functions will be baseline of
new 'parse() -> AST' functions.
Without a pager configured (in `ui.pager` or `$PAGER`), running
`LC_CTYPE=foo jj log` would replace the Unicode characters in our
(Sapling's) "curved" graph style by escapes, like this:
```
@ 1d4ae2372dd2 martinvonz@google.com 2023-02-11 14:56:00.000 -08:00 a8eac1f9efe8
<E2><94><82> (no description set)
```
This fixes that by including the `LESSCHARSET=utf-8` environment
variable in our default `ui.pager` value.
We would like our default pager of `less -FRX` to also get passed
`LESSCHARSET=utf-8`. I don't like having defaults that the user can't
specify themselves, so this commits provides users with a way to pass
environment variables to their configured pager (or editor, or merge
tool, ...).
I didn't document this feature and I didn't add it to the config
schema because it seems it's going to be so rarely useful to users.
Supported values are,
- `none` for no author information,
- `full` for both the name and email,
- `name` for just the name,
- `username` for username part of the email,
- (default) `email` (or any other gibberish for that matter) for the full email.
This partially reverts the change in d7f64c07e0 "cli: handle last-minute
ui.write() error." In this commit, I tried to handle the case when the pager
process goes through env/sh, and exits immediately with "command not found".
However, I missed EPIPE could also occur when the pager was closed by user.
Apparently, hg is killed by SIGPIPE in that case (exits with 141), and chg
exits with 255. With this change, jj will silently exits with 3.
This works if the pager exits instantly and jj is slow enough to notice
EPIPE. If the pager exits late, no error would be reported.
Since the pager process is asynchronous, EPIPE could occur in
handle_command_result(). That's why I made it not panic.
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.
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.
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.
This prepares for adding method arguments support. Since a method argument
should be evaluated in the surrounding scope, its type will be
'TemplateProperty<I>', not 'TemplateProperty<J>' for the receiver type 'J'.
Then, the receiver of type 'TemplateProperty<I, Output = J>', and arguments
of type 'TemplateProperty<I, Output = Pn>' will be composed to an input of
type 'TemplateProperty<I, Output = (J, Pn...)>'.
wrap_fn() is removed since it's only useful for nullary methods, and we
no longer need Box<dyn> to abstract the return value.
We'll probably need a better abstraction, but a parameterized keyword
function is a good first step. This unblocks the use of parse_term() for
context-less properties (or literals). I'm going to add a proper support
for context-aware method arguments, but literals can be parsed without it.
parse_keyword() closure is passed by reference to avoid infinite expansion.
It's hard to read dark blue on black, at least with iTerm2's default
color scheme. Cyan makes it much more readable. That's the color
`cargo` uses. We could also consider coloring only the "Hint:" part
like `cargo` does. For errors, `cargo` colors the "Error:" part red
and uses bold/bright white for select parts of the message.
This allows us to insert a separator between non-empty template fragments.
Since FormattablePropertyTemplate::has_content() needs to extract
a TemplateProperty, using this function means the property function will
be evaluated twice, one by .has_content() and later by .format(). The cost
is basically the same as 'if(prop, " " prop)'.
I believe this isn't a good abstraction, but I need to add one more variant
for "at least n arguments" error. A stringified count like "2 to 3" could be
embedded in an error variant, but I don't think it's good idea to build error
message in that way.
The way I added support for processing custom global arguments - by
using the existing `dispatch_fn` - meant that it wouldn't be run if
`CliRunner::add_global_args()` was called before
`CliRunner::add_subcommand()` and the custom subcommand wasn't
run. That's clearly not what I intended. This commit fixes that by
adding a separate list of functions for processing global args.
It's easier to mutate `self` than to create a new instance. It does
increase the risk of forgetting to update a field when adding a new
field or a new function, so maybe that's why @yuja did it this way?
Maybe I didn't make this change before because the closure needs to capture
WorkspaceId by value. Since the inlined version looks pretty simple, let's
go forward to do that.
We have moved from saying "committing the working copy" towards saying
"snapshotting the working copy". More importantly, the option also
means that we don't update the working copy at the end. I went with
the `--ignore-working-copy` name suggested by Ilya. I also updated the
documentation of the option.
