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".
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
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).
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.
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.
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.
As described in #5909, in the case where jj was initialized in a
shallowly cloned repository which was then unshallow'd, jj does not
import the fetched commits that were outside the shallow boundary.
However, it does import the ones after the boundary, which after
unshallowing do not contain the changes made before the boundary.
Therefore, when running annotate in such a case, jj would panic because
it does not find the commit from which a line originates. This sets the
empty commit as carrying the blame for that line.
All "short" formats should be able to be combined with -p/--patch. It was also
weird that "short" diff stats followed "long" color-words/git diffs.
Fixes#5986
`jj resolve` will currently try to resolve the executable bit and will
clear it if it can't be resolved. I don't think the executable bit
should be affected by the external merge tool. We could preset the
flags on the files we pass to the merge tool and then expect the merge
tool to update the flags, but we don't do that. I'm not sure that's a
good idea (few merge tools probably expect that), but since we don't
do it, I think it's better to leave the executable bits
unchanged. This patch makes it so by calling
`Merge::with_new_file_ids()` on the original conflict whether or not
the content-level conflict was resolved.
I noticed this was while working on the copy-tracking proposal in PR
#4988, which involves adding copy information in the `TreeValue`. If
we do implement that, then we should preserve copy information here
too (in addition to the executable flag). That will automatically work
after this patch.
If we add copy info to `TreeValue::File`, we will want to preserve
that when the user runs `jj chmod`. It's easier to preserve it by
updating the `Merge<Option<TreeValue>>` in place, so that's what this
patch does.
We could replace clap's "SuggestedSubcommand" instead of removing it,
but then the user might not notice that this is a custom suggestion and
not pay enough attention to it.
This uses the just-released https://github.com/clap-rs/clap/pull/5941.
There are alternative ways to solving the problem addressed by the next
commit, but they don't seem to preserve color well. So, let's have a
test to make sure future refactorings can tell whether this issue is
still relevant.
This removes the special case for RefName::LocalBranch(_), which can be
processed as a remote bookmark.
"jj git import" now prints local bookmarks and tags with @git suffix. I think
this is more correct since these refs are imported from the backing Git
repository.
