Includes diff tools, diff editors, and merge editors.

Now we should use the evolution API which queries op.commit_predecessors first.

The output cannot be templated as of now. Maybe we can add a template type for
Commit + Operation?

Closes #963

This is slower than traversing commit.predecessor_ids, but allows us to show
associated operations alongside the commits. Since operations are (mostly)
traversed in chronological order, the evolution graph is also emitted in that
order.

Bumps the github-dependencies group with 3 updates: [taiki-e/install-action](https://github.com/taiki-e/install-action), [rui314/setup-mold](https://github.com/rui314/setup-mold) and [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv).


Updates `taiki-e/install-action` from 2.51.2 to 2.52.1
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/941e8a4d9d7cdb696bd4f017cf54aca281f8ffff...6c6479b49816fcc0975a31af977bdc1f847c2920)

Updates `rui314/setup-mold` from e16410e7f8d9e167b74ad5697a9089a35126eb50 to 67424c1b3680e35255d95971cbd5de0047bf31c3
- [Commits](https://github.com/rui314/setup-mold/compare/e16410e7f8d9e167b74ad5697a9089a35126eb50...67424c1b3680e35255d95971cbd5de0047bf31c3)

Updates `astral-sh/setup-uv` from 6.0.1 to 6.1.0
- [Release notes](https://github.com/astral-sh/setup-uv/releases)
- [Commits](https://github.com/astral-sh/setup-uv/compare/6b9c6063abd6010835644d4c2e1bef4cf5cd0fca...f0ec1fc3b38f5e7cd731bb6ce540c5af426746bb)

---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-version: 2.52.1
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: github-dependencies
- dependency-name: rui314/setup-mold
dependency-version: 67424c1b3680e35255d95971cbd5de0047bf31c3
dependency-type: direct:production
dependency-group: github-dependencies
- dependency-name: astral-sh/setup-uv
dependency-version: 6.1.0
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: github-dependencies
...

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

Bumps the cargo-dependencies group with 2 updates: [os_pipe](https://github.com/oconnor663/os_pipe.rs) and [tokio](https://github.com/tokio-rs/tokio).


Updates `os_pipe` from 1.2.1 to 1.2.2
- [Commits](https://github.com/oconnor663/os_pipe.rs/compare/1.2.1...1.2.2)

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

---
updated-dependencies:
- dependency-name: os_pipe
dependency-version: 1.2.2
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: tokio
dependency-version: 1.45.1
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

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

Make `jj show` accept the same short forms, `-b` and `-w`, as `jj diff`
for the `--ignore-space-change` and `--ignore-all-space` options.

Operation ids in test_op_abandon*() are changed because reparented operations
now preserve the predecessors mapping.

Since this patch will affect whether "jj evolog" can show the associated
operations, I added a changelog entry. It's still a bit vague, but I think we
can add a more detailed explanation later.

There are two major goals:
1. garbage-collect predecessor commits referenced by immutable commits.
2. show operations alongside predecessors in "jj evolog".

The predecessors field will be removed from the Commit object. Maybe we can
also remove (writer side of) the extras table from GitBackend.

"jj evolog" will traverse the operation history to build an evolution
graph. This will be slower than the current implementation, but it seems
tolerable for mid-size repository stored in a local disk.

(when the page cache is warm)
% time jj op log -T'"."' --no-graph | wc -c
50459
jj op log -T'"."' --no-graph 0.12s user 0.31s system 103% cpu 0.418 total

Suppose we're interested in recent modifications, the traversal can often be
terminate early. I also have an idea for indexing originating operations.
https://github.com/jj-vcs/jj/pull/6405

For old operations which didn't record predecessors, "jj evolog" will fall back
to commit.predecessor_ids(). That's why commit_predecessors is Option<_>.

This version describes a design that I think will work relatively well
for supporting copy tracing even when there are conflicts.

There are still some open questions, in particular around how to
populate the data in Git repos, and how to efficiently query the data
in very large repos like the one at Google. I think it's still clear
enough that we can start working on the implementation.

closes #6587

Given a commit history like this:
○ ccc
○ bbb
◆ aaa

Parallelize *should* be able to create this:
○ ccc
│ ○ bbb
├─╯
│ ◆ aaa
├─╯

This is fine because `aaa` will not be rewritten --- its children will,
but neither `aaa`'s parents nor author information needs to be changed.

However, the current implementation checks _all_ commits in the
target set for rewritability, instead of only the commits that will
be rewritten.

This commit changes that. Now, only the commits whose parents *will*
change are checked for rewritability.

Just to make similar code look similar for easier
grepping/understanding.

With this enabled, clicking on a content tab will activate all tabs with the same label.
For example, clicking on any `Dynamic` tab on the docs/install-and-setup.md page will
show each shell's command to enable dynamic completions all at once. See [0] for more
details.

[0]: https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#linked-content-tabs

The op log should show the same command as on line 270.

The commit id prefix here should be `f7fb5943`, from the working copy's parent before
the squash (on line 351). Also see line 413 where the full commit id is shown in the
`Undid operation` message.

Using the `cfg_attr` attribute means the test is still compiled on non-macOS
architectures and checked but is ignored and not run, instead of running and passing.

This partially reverts f1765183 (from #6602) to avoid i18n issues as @yuja pointed out.

This is mostly for consistency with `read_file()` at this point. I'm
not sure if we need this for Google in the near future.

For now, I wrapped the file-reading in `local_working_copy.rs` in a
new `BlockingAsyncReader`. We should switch to using async I/O in the
future.

Deprecated in b57dd4d2 (#4014) and v0.20.0.

Fixup to 96e73bda.

Instead of checking if the parent op id is contained in the bad op's description
metadata, we construct the "undo operation X" description for the bad op on the fly
(using the parent op id X) and compare it with the existing bad op description.

We already use "conflicted commit" at the very end of the hint, so I've reused that term
here.

The optional arguments for each shell were deprecated in #2945 and v0.19.0.

The `shell` argument is now required, and Bash completions are no longer generated by
default if `jj util completion` is run without any arguments.

Dynamic completions were added to fish [4.0.2]. To date there is no 4.1 yet.

[4.0.2]: https://github.com/fish-shell/fish-shell/releases/tag/4.0.2

To identify an `undo` operation, checking that the views of the "bad" op and its
grandparent are equal is necessary but not sufficient. For example, creating a bookmark
and then immediately deleting it also "resets" the view. This commit fixes this by also
checking the "description" in the operation metadata to identify "double undo" properly.

With this commit, the "double undo" warning is now shown whether users undid the latest
undo implicitly (with `jj (op) undo`) or explicitly (with `jj (op) undo <op set>` or `jj
(op) undo @`).

If undoing an older undo (prior to `@`), the warning is not shown.

- Undoing latest undo explicitly with `jj undo @`.
- Undoing an older undo (that is not the most recent operation).
- Undoing an undo multiple times.
- Undoing a bookmark deletion (a spurious "double undo" warning is shown).

The test snapshots serve to indicate point-in-time behavior, so we shouldn't encode the
behavior in the test names. A later commit will change the current behavior so that
undoing the latest undo explicitly by op id or with the `@` symbol will no longer differ
in whether a warning is shown.

Incidentally, there is currently no difference in behavior between `jj undo` ("bare
undo") and `jj op undo`, as the former simply shells out to the latter.

The new name better communicates the intent of this function, and a different function
called `is_undo_of` that compares the "description" metadata of the operations instead
will be introduced in a later commit.

Using `exactly_one()` avoids an allocation.

A warning alerts users to a situation they may not have expected, which applies here.

The warning now explicitly calls out which `undo` has been reverted by which `undo`.
Also made the following hint more concise.

This is more consistent with `jj abandon`. I also changed the wording
from "skipped" to "abandoned" to make it more clear.

This fixes a bug where the rebase wouldn't work properly if a root of
the target commit set was abandoned before being rebased.

Instead of calling `move_commits`, callers now have the option to call
`compute_move_commits` and then customize the rebase before calling
`ComputedMoveCommits::apply`. `ComputedMoveCommits::record_to_abandon`
can be used to abandon commits while rebasing.

If the root of the target commit set is abandoned, it prevents the
commits from being rebased properly.

Introduced in b970939804b865729a1d14cedb6ea045411882b8 and caught by `cargo check`.

As suggested in Discord: https://discord.com/channels/968932220549103686/1370632916169920523

Also removes the 0.2 transitive getrandom dependency

The `Backend::read_file()` method is async but it returns a `Box<dyn
Read>` and reading from that trait is blocking. That's fine with the
local Git backend but it can be slow for remote backends. For example,
our backend at Google reads file chunks 1 MiB at a time from the
server. What that means is that reading lots of small files
concurrently works fine since the whole file contents are returned by
the first `Read::read()` call (it was fetched when
`Backend::read_file()` was issued). However, when reading files that
are larger than one chunk, we end up blocking on the next
`Read::read()` call. I haven't verified that this actually is a
problem at Google, but fixing this blocking is something we should do
eventually anyway.

This patch makes `Backend::read_file()` return a `Pin<Box<dyn
AsyncRead>>` instead, so implementations can be async in the read part
too.

Since `AsyncRead` is not yet standardized, we have to choose between
the one from `futures` and the one from `tokio`. I went with the one
from `tokio`. I picked that because an earlier version of this patch
used `tokio::fs` for some reads. Then I realized that doing that means
that we have to use a tokio runtime, meaning that we can't safely keep
our existing `pollster::FutureExt::block_on()` calls. If we start
depending on tokio's specific runtime, I think we would first want to
remove all the `block_on()` calls. I'll leave that for later. I think
at this point, we could equally well use `futures::io::AsyncRead`, but
I also don't know if there's a reason to prefer that.

It doesn't make sense to use the `Read` instance after calling
`write_file()`, so the caller shouldn't need to hold on to the
instance.

This slightly simplifies a later patch replacing `Read` by
`AsyncRead`.

This way `read_conflict()` more clearly doesn't need to worry about
non-utf8 data. It also makes a subsequent change to make `read_file()`
return an `AsyncRead` simpler.

The `expr` and `candidates` values do not match, because currently `expr` is always the
full op set expression being resolved.

We don't want to derive `PartialEq` on `OpsetResolutionError` because we may need an
`Other` variant in the future that wraps a type without a `PartialEq` implementation.
Pattern-matching is used instead to assert the contents.

This serves a similar purpose to Git's patch ID mechanism, however it is
slightly different in that it only compares commits which have the same
change ID as each other (divergent changes), and it does a full
comparison of the commits to see if they would have identical trees if
rebased onto the same parents. Since most changes aren't divergent, I
believe this should have a negligible performance cost in most cases.

I think skipping these commits by default makes sense for `jj rebase`,
since usually this will be a helpful behavior for the user. With this
behavior, a safe first step when encountering divergent changes would be
to rebase one branch on top of the other, since that will abandon any
divergent changes that have identical contents to existing commits,
leaving behind any non-trivial divergent changes for the user to resolve
manually.

Bumps the github-dependencies group with 2 updates: [taiki-e/install-action](https://github.com/taiki-e/install-action) and [github/codeql-action](https://github.com/github/codeql-action).


Updates `taiki-e/install-action` from 2.50.10 to 2.51.2
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/83254c543806f3224380bf1001d6fac8feaf2d0b...941e8a4d9d7cdb696bd4f017cf54aca281f8ffff)

Updates `github/codeql-action` from 3.28.17 to 3.28.18
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/github/codeql-action/compare/60168efe1c415ce0f5521ea06d5c2062adbeed1b...ff0a06e83cb2de871e5a09832bc6a81e7276941f)

---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-version: 2.51.2
dependency-type: direct:production
update-type: version-update:semver-minor
dependency-group: github-dependencies
- dependency-name: github/codeql-action
dependency-version: 3.28.18
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...

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

Disclaimer: I am not associated with jjui, but enjoy using it.

`jj branch` has been deprecated since v0.22.0.

`renamed_cmd()` has no more callers now and has been removed. It can be added back in if
needed in the future.

The `jj branch` mentions in docs/design/tracking-branches.md have been left as they are
as a historical record since that document hasn't been updated since June 2024.