Before, it was easy to have a bug in tests where a command is accidentally
non-mutating (or accidentally mutating), and so `undo` undid the wrong command.

This will be done to remaining tests in a separate PR.

I use the function very liberally: it's easier to add it than
to think about whether it's needed.

`vimtabdiff` has a few potential advantages:

- It can be much more convenient for diffs with few files
- It can be easier to set up for some people (it is a Python script rather
than a Vim plugin).
- The author accepts patches, and I hope to make it support 3-pane diff.

The pros and cons are also described in the linked Gist.

When the main `TreeState::snapshot()` thread doesn't receive any
updated tree entries over the channel, it correctly doesn't write a
new tree. However, it also doesn't write the working copy state file
(`.jj/working_copy/tree_state`). This resulted in performance
regression in 3f97a6da783a7. From that commit, repeated snapshotting
would have to re-read all files from disk because it didn't remember
the updated mtime from the previous time.

This patch fixes the bug by also writing the file if there were any
new file states.

This doesn't seem to make any difference right now, but it will if we
write the state file when there are mtime-only changes, which we
currently don't do.

There's no need for it to allocate the variable names, and the only place it's
currently used can benefit from returning early if `$output` is found

Bumps the cargo-dependencies group with 1 update: [slab](https://github.com/tokio-rs/slab).

- [Release notes](https://github.com/tokio-rs/slab/releases)
- [Changelog](https://github.com/tokio-rs/slab/blob/master/CHANGELOG.md)
- [Commits](https://github.com/tokio-rs/slab/compare/v0.4.8...v0.4.9)

---
updated-dependencies:
- dependency-name: slab
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

Mutex::new and Slab::new are both const, so we can use a static mutex directly

This avoids repeating the `n` in these expressions. Thanks to
@Dr-Emann for the suggestion.

As discussed in https://github.com/martinvonz/jj/discussions/1905#discussioncomment-6589673

To be used in the next commit

To me, this behavior seems a bit unexpected. We may want to fix it later

Bumps the cargo-dependencies group with 3 updates: [clap](https://github.com/clap-rs/clap), [serde](https://github.com/serde-rs/serde) and [tempfile](https://github.com/Stebalien/tempfile).


Updates `clap` from 4.3.22 to 4.3.23
- [Release notes](https://github.com/clap-rs/clap/releases)
- [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md)
- [Commits](https://github.com/clap-rs/clap/compare/v4.3.22...v4.3.23)

Updates `serde` from 1.0.183 to 1.0.185
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.183...v1.0.185)

Updates `tempfile` from 3.7.1 to 3.8.0
- [Changelog](https://github.com/Stebalien/tempfile/blob/master/CHANGELOG.md)
- [Commits](https://github.com/Stebalien/tempfile/compare/v3.7.1...v3.8.0)

---
updated-dependencies:
- dependency-name: clap
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: tempfile
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

`revset::parse()` already has a `RevsetWorkspaceContext` argument, so
I think it makes sense to put that and the other context arguments
into a larger `RevsetParseContext` object.

We resolve file paths into repo-relative paths while parsing the
revset expression, so I think it's consistent to also resolve which
workspace "@" refers to while parsing it. That means we won't need the
workspace context both while parsing and while resolving symbols.

In order to break things like `author("martinvonz@")` (thanks to @yuja
for catching this), I also changed the parsing of working-copy
expressions so they are not allowed to be
quoted. `author(martinvonz@)` will therefore be an error now. That
seems like a small improvement anyway, since we have recently talked
about making `root` and `[workspace]@` not parsed as other symbols.

Add tests for new UTC timestamp format

Add documentation for timestamp utc

Update CHANGELOG.md

Custom binaries will often want to provide e.g. additional command
aliases, additional revset aliases, custom colors, etc. This adds a
mechanism for them to do that.

Per discussion in #2107, I believe "exact" is preferred.

We can also change the default to exact match, but it doesn't always make
sense. Exact match would be useful for branches(), but not for description().
We could define default per predicate function, but I'm pretty sure I cannot
remember which one is which.

git-branchless calls it a substring, so let's do the same.

FWIW, I copied literal:_ from Mercurial, but it's exact:_ in git-branchless.
I have no idea which one is preferred. Since this feature isn't released, we
can freely change it if exact:_ makes more sense.

https://github.com/arxanas/git-branchless/wiki/Reference:-Revsets#patterns

New placeholders say "(no name availalbe)" and "(no email available)",
because empty strings aren't _necessarily_ a configuration issue.

This commit replaces the functions `UserSettings::user_name_placeholder()`` and
`UserSettings::user_email_placeholder()` with `const` `&str`s to emphasize that
the placeholder strings must not be changed to support commits without
names or email addresses made before this change.

Bumps the cargo-dependencies group with 4 updates: [anyhow](https://github.com/dtolnay/anyhow), [clap](https://github.com/clap-rs/clap), [thiserror](https://github.com/dtolnay/thiserror) and [tokio](https://github.com/tokio-rs/tokio).


Updates `anyhow` from 1.0.74 to 1.0.75
- [Release notes](https://github.com/dtolnay/anyhow/releases)
- [Commits](https://github.com/dtolnay/anyhow/compare/1.0.74...1.0.75)

Updates `clap` from 4.3.21 to 4.3.22
- [Release notes](https://github.com/clap-rs/clap/releases)
- [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md)
- [Commits](https://github.com/clap-rs/clap/compare/v4.3.21...v4.3.22)

Updates `thiserror` from 1.0.46 to 1.0.47
- [Release notes](https://github.com/dtolnay/thiserror/releases)
- [Commits](https://github.com/dtolnay/thiserror/compare/1.0.46...1.0.47)

Updates `tokio` from 1.31.0 to 1.32.0
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](https://github.com/tokio-rs/tokio/compare/tokio-1.31.0...tokio-1.32.0)

---
updated-dependencies:
- dependency-name: anyhow
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: clap
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: thiserror
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: tokio
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

This is another small step towards making this code work with
tree-level conflicts.

There's a lot of duplication between the blocks of code for updating
modified and added paths. This commit combines them.

This is also just to make the next change simpler.

This just a little refactoring to make the next step of sharing code
between `Modified` and `Added` simpler.

The code for getting the current tree object was repeated a few times
over. I'm going to soon make it return a `MergedTree` and I don't want
to repeat that code (it's more complicated than the current code).

Bright green really pops on my screen, and I don't think there is a reason
for the root commit to be attention-grabbing.

This follows up on https://github.com/martinvonz/jj/pull/2084.

user_email is always available to the revset parser.

The syntax is slightly different from Mercurial. In Mercurial, a pattern must
be quoted like "<kind>:<needle>". In JJ, <kind> is a separate parsing node, and
it must not appear in a quoted string. This allows us to report unknown prefix
as an error.

There's another subtle behavior difference. In Mercurial, branch(unknown) is
an error, whereas our branches(literal:unknown) is resolved to an empty set.
I think erroring out doesn't make sense for JJ since branches() by default
performs substring matching, so its behavior is more like a filter.

The parser abuses DAG range syntax for now. It can be rewritten once we remove
the deprecated x:y range syntax.

Bumps the cargo-dependencies group with 1 update: [serde_json](https://github.com/serde-rs/json).

- [Release notes](https://github.com/serde-rs/json/releases)
- [Commits](https://github.com/serde-rs/json/compare/v1.0.104...v1.0.105)

---
updated-dependencies:
- dependency-name: serde_json
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

Add type annotation to `vec` to avoid the following build error if you
additionally import `bstr`:

```
~/jj> cargo test
Compiling jj-lib v0.8.0 (/home/aspotashev/jj/lib)
warning: unused import: `bstr`
--> lib/src/default_index_store.rs:30:5
|
30 | use bstr;
| ^^^^
|
= note: `#[warn(unused_imports)]` on by default

error[E0282]: type annotations needed
--> lib/src/default_index_store.rs:564:14
|
564 | .as_mut()
| ^^^^^^
565 | .write_u32::<LittleEndian>(parent_overflow.len() as u32)
| --------- type must be known at this point
|
help: try using a fully qualified path to specify the expected types
|
563 | <[u8] as AsMut<T>>::as_mut(&mut buf[parent_overflow_offset..parent_overflow_offset + 4])
| +++++++++++++++++++++++++++++++ ~

For more information about this error, try `rustc --explain E0282`.
warning: `jj-lib` (lib) generated 1 warning
error: could not compile `jj-lib` (lib) due to previous error; 1 warning emitted
```

Reason to support `bstr` being imported: in a Bazel environment where
crates are imported with certain features enabled, jj-lib may pull in
bstr as part of the following dependency chain:
jj-lib -> insta -> similar -> bstr.

One use case for `jj split` is when creating a new commit from some of
the changes in the working copy. If there's no description on the
working-copy commit in that case, it seems better to not ask the user
to provide one when they're splitting the commit either.

Bumps the cargo-dependencies group with 2 updates: [anyhow](https://github.com/dtolnay/anyhow) and [thiserror](https://github.com/dtolnay/thiserror).


Updates `anyhow` from 1.0.72 to 1.0.74
- [Release notes](https://github.com/dtolnay/anyhow/releases)
- [Commits](https://github.com/dtolnay/anyhow/compare/1.0.72...1.0.74)

Updates `thiserror` from 1.0.44 to 1.0.46
- [Release notes](https://github.com/dtolnay/thiserror/releases)
- [Commits](https://github.com/dtolnay/thiserror/compare/1.0.44...1.0.46)

---
updated-dependencies:
- dependency-name: anyhow
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: thiserror
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>

#2062 missed this. Partially addresses #1354.

I've extracted the `builtin_log_root` template for users to customize the
default templates without fully overriding them, for example I would remove
the change_id/commit_id for myself - and we discussed in Discord that leaving
those makes sense for the user to be reminded/teached that the root commit has
a change id made from z's.

Similar to other boolean flags, such as "working_copy" or "empty".
We could test something like
`"0000000000000000000000000000000000000000".contains(commit_id)`
like I did for myself, but first of all this is ugly, and secondly the root
commit id is not guaranteed to be 40 zeroes as custom backend implementations
could have some other root.