To avoid redundant computation, users who run `COMPLETE=fish jj | source`
in their ~/.config/fish/config.fish should eventually remove that, or move it
to ~/.config/fish/completions/jj.fish which overrides the default completions.

Ref: https://github.com/fish-shell/fish-shell/pull/11046

This makes it clear to source code readers, that it isn't the _native backend_ the project
talks about in the Roadmap.

This was causing unnecessary rebuilds in the test step due to the
changed environment variable.

The stock version seems to be sufficient these days.

The stock version seems to be sufficient these days.

This adds a revert command which is similar to backout, but adds the
`--destination`, `--insert-after`, and `--insert-before` optoins to
customize the location of the new reverted commits.

`jj backout` will subsequently be deprecated.

Closes #5688.

Suppose we add "jj file annotate" option to specify the search domain or depth,
the root commit within the range can be displayed as the boundary commit. "git
blame" for example displays boundary commits with ^ prefix.

This follows up 85e0a8b0687e "annotate: add option to not search all ancestors
of starting commit."

It's not important to remove anyhow dependency, but there was no reason to use
anyhow.

I feel it's easier to follow if types are defined first.

We generally use panicking functions in tests.

The TestCase type will be a pure value type.

We don't care about the memory layout here, and it'll become verbose to spell
them out in the following patches.

The code in this area gets significantly simpler, since there's no
longer any ambiguity to resolve. The scm-record changes expect that any
mode changes are represented by file mode sections, and adds UI hooks to
simplify working with them (e.g. automatically de-selecting a deletion
mode change if any lines in the file are de-selected, since the file
still needs to exist to hold those lines).

If the user selects a file mode change, the new mode comes back as part
of .get_selected_contents(), so we can use this directly to figure out
whether the file was removed or just changed.

* The lib part should not deal with tools, or tool config, or running stuff in subprocesses. That stays in the CLI.
* Adds a fix_files function. This is the entry point.
* Adds a FileFixer trait with a single method to process a set of files. This is a high-level plugin point.
* Adds a ParallelFileFixer which implements the FileFixer trait and invokes a function to fix one file a time, in parallel.
* The CLI uses ParallelFileFixer.

The FileFixer trait allows environments (other than jj CLI) to plug in their own implementation; for example, a server could implement a FileFixer that sends RPCs to a "formatting service".

Just using the fastest platform should be fine for this. Hopefully it
shouldn’t slow down CI too much since it’s an independent build
job and only temporary, though a potential alternative would be to
just check the build instead. (It wouldn’t catch build regressions
in the test code, though.)

This helps us prepare for removing the functionality down the line and
makes things easier for people building or packaging their own Jujutsu.

The fetch and push code are the only remaining users of this, so
let’s not encourage adding any more.

The current behaviour means (transitively) dependent crates' debug logs end up
in our logs when `--debug` is active.

The biggest offender here is `globset`, imported from the `ignore
crate`. These logs are extremely noisy and mostly irrelevant from our usecase.

This commit changes this behaviour to whitelist `jj` related debug logs,
while allowing more debugging to come from env vars

If a signing key is not configured, the user's email will be
used as the signing key. This aligns with `git`'s behavior
and allows the users to not specify the key in their configs
given that they have a key associated with their email.

This helps avoid loading errors should the JJ_CONFIG
environment variable be set to a directory that
contains other file types.

Bumps the github-dependencies group with 1 update: [taiki-e/install-action](https://github.com/taiki-e/install-action).


Updates `taiki-e/install-action` from 2.49.19 to 2.49.22
- [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/87b5304d4e82236718783683826c899da7e5470f...4a7eafa27f0bd6857fe4f46dad5c66568c426ac0)

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

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

Multiple user configs are now supported and are loaded in the following precedence order:
- `$HOME/.jjconfig.toml`
- `$XDG_CONFIG_HOME/jj/config.toml`
- `$XDG_CONFIG_HOME/jj/conf.d/*.toml`

Which removes the need to set `JJ_CONFIG` for a multi-file approach.
Later files override earlier files and the `JJ_CONFIG` environment
variable can be used to override the default paths.

The `JJ_CONFIG` environment variable can now contain multiple paths separated
by a colon (or semicolon on Windows).

When using old git versions, some of the options we use
(namely, --no-write-fetch-head #5933), we want to report that the error
comes from the outdated git, instead of cryptically failing.

Closes #5933

It's easier to process index than re-parsing stringified choice.

Follows up 0c7357ec5f55 "ui: write prompt messages to stderr."

I also removed &mut since writing to Ui doesn't require mutable reference.

This code has been unused since 8e6e04b92.

I also deleted the associated tests. I considered porting them to
`MergedTree` but it looks like we have good coverage of these cases in
the existing `MergedTree` tests combined with the low-level `Merge`
tests.

This works around borrowing issue of test_env.

This works around borrowing issue of test_env.

This is our convention, and helper functions can be hidden from the builtin
aliases list.

Cow<str> provides .into_owned(). I don't care much about .to_string() vs
.to_owned(), but it was originally .to_owned(), so reverted the change.

I just happened to see that there's a new(ish) version out. It removed
all unsafe code, apparently.

Bumps the cargo-dependencies group with 3 updates in the / directory: [once_cell](https://github.com/matklad/once_cell), [tempfile](https://github.com/Stebalien/tempfile) and [tokio](https://github.com/tokio-rs/tokio).


Updates `once_cell` from 1.21.0 to 1.21.1
- [Changelog](https://github.com/matklad/once_cell/blob/master/CHANGELOG.md)
- [Commits](https://github.com/matklad/once_cell/compare/v1.21.0...v1.21.1)

Updates `tempfile` from 3.18.0 to 3.19.0
- [Changelog](https://github.com/Stebalien/tempfile/blob/master/CHANGELOG.md)
- [Commits](https://github.com/Stebalien/tempfile/compare/v3.18.0...v3.19.0)

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

---
updated-dependencies:
- dependency-name: once_cell
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
- dependency-name: tokio
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...

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

We no longer have external callers of git_init() functions.

I'm thinking of adding RefName(str) and RemoteName(str) newtypes, and the
templater type name would conflict with that. Since the templater RefName type
is basically a (name, target) pair, I think it should be called a "Ref", and I
added "Commit" prefix for disambiguation.

This isn't a breaking change since template type names only appear in docs and
error messages.

For `builtin_log_compact` you can specify how you want signatures to be
displayed via `format_short_signature`, but the same wasn't possible for
`builtin_log_compact_oneline` which always chose `email().local()`.

When we push a ref to a git remote, we use --force-with-lease
Our understanding was that this could fail iff the expected location of
the ref on the remote was not that of the local tracking ref

However, if the ref is from a protected branch (e.g., main) it will be
rejected by the remote for a different reason.

This commit solves this, by detecting this difference.

Mainly, the reason is not separated by a tab, but rather a space
Additionally, the test output was made more realistic

Adds a `templates.config.list` config option to control whether the
detailed list is shown or not.

The `builtin_config_list_detailed` template adds the config origin to
the end of the line for each config value in the list. Options coming
from files will show the file path.

I think this will reduce some noise from skipped checks in the UI.

It turns out that merge queues bundle auto‐merge for free, so we
can just do this the old way.

This backs out commit eba4257ab9a0268460108c234dc0d046efcd6c33.

Ideally we’d just cancel workflows entirely when they’re ejected
from the merge queue but apparently that’s kinda hard for some
inexplicable reason. This should be a cheap and harmless win. I
guess it gives you slightly less information if something fails
because of changes in the queue but you can just rebase your PR to
get everything running.

I don’t think `github.event.merge_queue.head_ref` actually does
anything useful, but I’m not sure if `github.ref` works for merge
groups and it seems better to have a fallback than not. I’d really
like to cancel PR workflows when a PR enters the merge queue, and
cancel queue workflows when a PR is ejected from the merge queue,
but apparently this simple task is high‐level wizardry when you’re
using GitHub Actions, so I’m postponing that for later.

This was running all the checks twice for pushes to pull requests,
unnecessarily limiting our concurrency and clogging up the status
report. The only benefit is if someone is pushing to a branch that
they don’t have a PR for and waiting for the checks to run. I
suspect nobody is doing this with regularity, but if it turns out
the functionality is important, we could just ask people to add this
back to the `.github/workflows/ci.yml` on the branches they want
GitHub to test, or add logic to try and cancel `push` runs that match
`pull_request` ones.