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.
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 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".
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.
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
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.
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.
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.
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.
Suppose revsets and filesets are primarily used in command shell, it would be
annoying if quoting is required in addition to the shell quoting. We might also
want to relax the revset parser to allow bare * in glob string.
Closes#2101
I'm going to reimplement git_ref_filter to process translated remote bookmark
names, and "git" remote will mean the local Git-tracking remote there. The
reserved remote name is checked prior to filtering because refs in that remote
cannot be represented as remote symbols.
I originally implemented the error handling the other way because we didn't
have a machinery to report partial import failure. Now we have stats, it's
easy to report skipped ref names.
It's odd that "foo/bar" is tested earlier in push_branches() whereas "git" is
rejected by push_updates(). Suppose push_updates() is a low-level function to
push arbitrary refs without updating jj's repo view, it's probably okay to allow
unsupported remote name here.
