Closes#5217
Motivating use case:
[[--scope]]
--when.command = ["log"]
[--scope.ui]
pager = "less"
This adds a new (optional) field to `--when` config conditions, to
inspect the current command.
`--when.commands` is a list of space-separated values that matches a
space-separated command. To be specific:
--when.command = ["file"] # matches `jj file show`, `jj file list`, etc
--when.command = ["file show"] # matches `jj file show`, but *NOT* `jj file list`
--when.command = ["file", "log"] # matches `jj file` *OR* `jj log` (or subcommand of either)
When both `--when.commands` and `--when.repositories` are set, the
intersection is used.
In some cases, there are non trivial codepaths for fetching multiple
branches explicitly. In particular, it might be the case that fetching
works for n = 2 but not n = 3.
This commit changes a cli test to have 3 remotes and 3 branches, and a
lib test with 3 branches, only one of them succeds.
Fully qualified git refs (e.g., `+refs/head/main:refs/remotes/origin/main`)
are commonly used throughout the git glue code.
It is laborious and error prone to keep parsing refspecs when we need
only a segment of it.
This commits adds a type, `RefSpec`, which does exactly that
It's not uncommon to insert new table at a certain path. This could be modelled
as set_table(name, new_table), but the caller might want to merge items with
the existing table if any. This function can be used for both cases.
This was needed in order to migrate fix.tool-command to [fix.tools] table. We
don't have other use cases right now, but there will be something in future.
I'll make "jj abandon" delete bookmarks by default. This could be handled by
cmd_abandon(), but we'll need a repo API if we also want to change the behavior
of "jj rebase --skip-emptied".
I noticed that some config structures do not use their "Default" implementation, and have their default specified in a TOML file. I think specifying defaults in TOML is great, and it'd be good to delete those Default implementations, so that it does not diverge from the default in the TOML file.
There's only one non-test caller who doesn't need a complete map of rebased
commits.
FWIW, I tried to rewrite squash_commits() based on transform_descendants() API,
but it wasn't easy because of A-B+A=A rule. The merge order matters here.
Tag and bookmark names are usually ASCII, but they occasionally include Latin
or Han characters.
This doesn't fix the serialization problem, but should mitigate #5359.
The "identifier" rule will be changed to accept unicode characters. It's not
super important to reject non-ASCII string pattern prefixes or alias symbols,
but this is more consistent with templater and fileset. We can relax the rule
later if needed.
This is a middle ground. An inline table can still be overwritten or deleted
because it's syntactically a value. It would be annoying if "jj config set
colors.<name> '{ .. }'" couldn't be executed more than once because the existing
item was a table.
#5255
Instead of resolving deprecated variables by callers or config object, this
patch adds a function that rewrites deprecated variables globally (and emits
warnings accordingly.) It's simpler because StackedConfig doesn't have to deal
with renamed variables internally. OTOH, warnings will be issued no matter if
variables are used or not, which might be a bit noisy.
Maybe we can also add "jj config migrate" command that updates user and repo
configs.
I have come to think of conflicts more and more as one positive
followed by a series of diffs and less as two separate sets of adds
and removes. We've already changed the implmentation of `Merge` to be
a single list of interleaved positive and negative terms. I think it's
simpler to use the same format in `trivial_merge()` too.
To keep the diff simple, I just preserved the test case values and
order as is for now even if that means that some of them are now
unintuitive. I'll clean that up in the next commit.
If many files are conflicted, it would be nice to be able to resolve all
conflicts at once without having to run `jj resolve` multiple times.
This is especially nice for merge tools which try to automatically
resolve conflicts without user input, but it is also good for regular
merge editors like VS Code.
This change makes the behavior of `jj resolve` more consistent with
other commands which accept filesets since it will use the entire
fileset instead of picking an arbitrary file from the fileset.
Since we don't support passing directories to merge tools yet, the
current implementation just calls the merge tool repeatedly in a loop
until every file is resolved, or until an error occurs. If an error
occurs after successfully resolving at least one file, the transaction
is committed with all of the successful changes before returning the
error. This means the user can just close the editor at any point to
cancel resolution on all remaining files.
There are some experiments to try and compile `jj` to WebAssembly, so that we
might be able to do things like interactive web tutorials. One step for that
is making `git` support in `jj-cli` optional, because we can stub it out for
something more appropriate and it's otherwise a lot of porting annoyance for
both gitoxide and libgit2.
(On top of that, it might be a useful build configuration for other experiments
of mine where removing the need for the large libgit2 depchain is useful.)
As part of this, we need to mark `jj-lib` as having `default-features = false`
in the workspace dependency configuration; otherwise, the default behavior
for Cargo is to compile with all its default features, i.e. with git support
enabled, ignoring the `jj-cli` features clauses.
Other than that, it is fairly straightforward junk; it largely just sprinkles
some `#[cfg]` around liberally in order to make things work. It also adjusts the
CI pipeline so this is tested there, too, so we can progressively clean it up.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
`zstd` is only used to write files in the native backend right now. For now,
jettison it, to unbundle some C code that we don't really need.
(Ideally, a future compression library would be pure Rust, but we'll cross that
bridge when we get to it...)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This backs out commit 0de36918e4. Documentation,
tests, and comments are updated accordingly. I also add ConfigTableLike type
alias as we decided to abstract table-like items away.
Closes#5255
If the parent tree contains conflicts, we want the index to also contain
a conflict to ensure that the use can't accidentally commit conflict
markers using `git commit`. Since we can't represent conflicts with more
than 2 sides in the Git index, we need to add a dummy conflict in this
case. We use ".jj-do-not-resolve-this-conflict" as the dummy conflict to
indicate to the user that they should not attempt to resolve this
conflict using Git.
Instead of setting the index to match the tree of HEAD, we now set the
index to the merged parent tree of the working copy commit. This means
that if you edit a merge commit, it will make the Git index look like it
would in the middle of a `git merge` operation (with all of the
successfully-merged files staged in the index).
If there are any 2-sided conflicts in the merged parent tree, then they
will be added to the index as conflicts. Since Git doesn't support
conflicts with more than 2 sides, many-sided conflicts are staged as the
first side of the conflict. The following commit will improve this.
