I don't think there's a good reason not to write the
`.jj/working_copy/tree_state` file on init. Being able to assume that
the file exists means that we won't need the store object to to lazily
load the `TreeState` object. Well, except that `TreeState` keeps an
`Arc<Store>`, but I'm trying to change that.
Before, "f()" was parsed as a function call with one empty argument. In
practice, this change means "if(divergent,,false_template)" is no longer
valid.
When building an initial index from an existing Git repo, for example,
we walk parents and predecessors to find all commits to index. Part of
that code was looking up the whole parent and predecessor commits even
though it only needed the ids. I don't know if this has a measurable
impact on performance, but it's not really any more complex to just
get the ids anyway.
Suppose "template" is a sequence of "term"s, it makes more sense to handle
an empty sequence there. It might be even better to disallow empty template
other than the top-level one.
A "list" is a sequence of more than one "term" nodes, so it shouldn't contain
a single parenthesized node.
Also, a parenthesized "term" rule wasn't handled.
I would expect `Commit::is_empty()` to check if the commit is empty in
our usual sense, i.e. that there are no changes compared to the
auto-merged parents. However, it would return `false` for any merge
commit (and for the root commit). Since we only use it in one place,
let's inline it there. The use there does seem reasonable, because
it's about abandoning an "uninteresting" working-copy commit.
We don't actually need `jj` itself in the development shell. But having it in
the overlay significantly increases the time it takes to build the shell.
Our installation instructions don't currently work with Rust < 1.64
because `clap` updated their MSRV to 1.64, and `cargo install` without
`--locked` bypasses `Cargo.lock` and selects the version of `clap`
that needs Rust 1.64.
A method call is typically parsed as (obj.meth)(), not as obj.(meth()),
but the latter is good enough for our needs. It's unlikely we'll add a
first-class function support.
.into_inner().next().unwrap() mess will be cleaned up by the next commit.
I think of it more as style than a format, so using `style` in the
config key makes sense to me.
I didn't bother making upgrades easy by supporting the old name since
this was just released and only a few developers probably have it set.
Now that the `renderdag` crate is available on crates.io (thanks,
@quark-zju!), let's get it from there.
It has no optional features, so we don't need `default-features =
false`. I should have done that when we switched from the `dag` crate
to the `renderdag` crate.
The heading says it's going to explain aliases, but it doesn't, and
now that we've documented aliases in config.md, we probably don't need
to mention it in the tutorial.
The name of the [alias] section is inconsistent with other
table-valued sections ([revset-aliases], [colors], [merge-tools]), so
let's rename it. For comparison, `Cargo.toml` also uses plural names
(e.g. `[dependencies]`).
I don't think need to write non-UTF8 bytes to our config files. If we
ever do (maybe to test that we give the user a reasonable error
message), we add a custom function for that.
This basically removes 'a lifetime from these wrappers, and add trait bounds
instead. I have no idea which version would look less scary, but let's see.
I also added trait bounds to constructor functions. They aren't strictly
required, but help type inference of closure (and will probably improve
an error message.)
Fixes#787
If `jj squash` is run on an empty commit, it fails with "Error: No changes selected"
With this change such squash command will behave like `jj abandon`.