It is important for this case to be an error, because otherwise it would
be possible to construct a non-conflicted commit which appears to have a
different tree when viewed using `jj` than when viewed using Git. This
could potentially be used to hide malicious code in commits in such a
way that on GitHub, the code would appear normal, but it would become
malicious when cloned using `jj`.
Prior to f7b14beacc, if a commit had a
`jj:trees` header with only a single tree, it would result in a panic of
"root tree should have been initialized to a legacy id". This commit
restores the error behavior by adding an explicit check for this case.
I have no immediate plan, but I think we can make "jj git export" show exported
refs. The FailedRefExport type is replaced with a plain tuple since we have a
named type wrapping (symbol, reason) pairs now.
We have been writing conflicted tree ids to the `jj:trees` commit
header since 4d426049 (just over a year ago) and we have been able to
read them from there since the same commit. This patch updates the
write path so we no longer redundantly write the trees to the proto
storage.
We write the `jj:trees` commit header since 4d426049. If the
information is written to that header, we should not require it to
also be in the proto storage.
I'm going to change the key type from RefName to RemoteSymbolBuf, but the std
BTreeMap/HashMap doesn't support lookup by un-Borrow-able ref types. We can use
hashbrown::HashMap, but there aren't popular alternative for ordered maps.
Since we don't need random insertion and lookup, we can simply use Vec.
When used inside GUI application, enabling GPG or SSH signing causes console window to appear temporarily.
std::process::Command needs special flags to prevent that. More details: https://stackoverflow.com/a/60958956
When used inside GUI application, git.subprocess=true option causes console window to appear temporarily.
std::process::Command needs special flags to prevent that. More details: https://stackoverflow.com/a/60958956
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 85e0a8b068 "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
