A new section clarifies that `JJ_CONFIG` replaces the default config
paths. I also reworded a few sentences to make them more precise.

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.

Some setup bits are reordered manually to work around mutable borrows.

We're going to add support for multiple user config paths, and it would be
weird if Unavailable could be included in a Vec.

This allows the user to select a particular file when using multiple
configs. In the event that a prompt cannot be displayed, the first
file will be automatically selected.

std::fs::rename() and symlink() aren't added to TestWorkDir. There are few
instances of rename(). work_dir.symlink() would be a bit unclear whether the
link content path is normalized, which usually shouldn't.

This works around borrowing issue of test_env.

The local work_dir is created by caller since it borrows &test_env.

Bumps the cargo-dependencies group with 1 update: [quote](https://github.com/dtolnay/quote).


Updates `quote` from 1.0.39 to 1.0.40
- [Release notes](https://github.com/dtolnay/quote/releases)
- [Commits](https://github.com/dtolnay/quote/compare/1.0.39...1.0.40)

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

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

This reports the status of the checks that are currently set as
required in the repository configuration, but only in the merge
queue. The advantages are twofold:

1. We can adjust required checks with our normal CI process rather
than having to bug Martin for it. (This doesn’t really place any
more trust in anyone than we do currently, because a malicious PR
could always just replace the jobs with ones that unconditionally
succeed anyway.)

2. We can make the job only ever fail in the merge queue. Currently,
we can only submit a PR into the merge queue after all its checks
pass. Those checks then immediately get run again in the merge
queue. If you do one final fix‐up to an approved PR, it takes
half an hour after that to merge instead of fifteen minutes. We
make this less painful by using auto‐merges, but it’s silly
to block on the PR checks when the actual guarantees are provided
by the merge queue.

Unfortunately GitHub demands the same jobs be required for putting
something into the merge queue and taking it out. We can work
around this by only requiring the `required-checks` job and having
it report its status depending on the context.

Tasks for Martin:

1. Go to <https://github.com/jj-vcs/jj/settings> and disable “Allow
auto-merge”. This would now only block on PR approval / discussion
resolution, so it’s probably more confusing than helpful; I’ve
hit the button and then come back an hour later to discover that
I forgot to resolve discussions.

Go to <https://github.com/jj-vcs/jj/settings/rules/3400426> and
replace all of the required GitHub Actions checks under “Require
status checks to pass” with the single `required-checks` check.

3. While you’re at it, go to
<https://github.com/jj-vcs/jj/settings/actions> and ensure that
“Workflow permissions” is set to “Read repository contents
and packages permissions”. We already handle this correctly in
all our workflows but the default is to allow write permissions
for legacy reasons.