I think "jj next/prev" prompt can also support selection by change ID prefix.
Maybe we can also add ui.prompt_choice_range(prompt, range, default) if that's
common?
This is barely worth doing, but since I did it once...
I feel that some people might treat the simple backend as an easter egg, and
this will help them know what to expect.
This removes warning about unused SimpleBackend on non-dev build. Since
Workspace::init_simple() isn't feature-gated, it doesn't make sense to disable
the backend loading.
In recent bugs, it's been really hard to triage the behaviour from the
existing debug logs.
In particular, there have been situations where the `git` command is not
enough to triage, because the bug stems from a particular
environment/config issue. Moreover, these bugs are either transient, and
as such hard to replicate, or they only manifest when spawning `git`
from `jj` (and as such re-running the `git` command does not yield
useful information).
In those cases, seeing what the subprocessing code is seeing becomes
very much useful. This commit adds some debug logging to help with this
problem, by logging some parts of the `git(1)` output and the config.
This shaves off something like 20 to 40 seconds for Linux. It’s
seemingly within the margin of error for Windows, so not sure if
we’ll want to keep it there.
This configuration is for the CI builders, so by moving it to another
file we can add more opinionated things without risking breaking
builds for anyone else.
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 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."
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.)
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.
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
