This commit clarifies the order in which `trunk()` is resolved following
commit 5fedd36 (git init: prefer `upstream` over `origin` for `trunk()`
alias).
This allows checking whether "any" or "all" elements in a list satisfy a given
predicate, similar to Python's native `any()` and `all()` functions, but
instead as list methods that take lambda predicates.
These new methods follow the same pattern as existing `filter` and `map`
operations, i.e. taking a lambda that receives each item and must return a
boolean.
This paves the way for the semantics of `jj undo` and `jj op revert` to
evolve independently. `jj op revert` is going to stay the low-level
command to apply the inverse of any operation. The new name is
consistent with `jj revert`, which applies the inverse of a commit.
`jj undo` on the other hand is planned to become a higher-level command,
which is more similar to, say, Ctrl+Z in typical GUI applications.
Running `jj undo` repeatedly will revert progressively older operations,
allowing the user to walk backwards in time. At the same time, `jj undo`
will lose the abilitly to revert arbitrary operations, to keep its
semantics simple and intuitive.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The flake/devShell is already configured to pull in a nightly version of
`rustfmt` which means running `rustfmt +nightly` will actually fail
(since we aren't pulling in `rustup`).
On Windows, spawning a child process finds the command relative to the
parent's working directory. If a command is specified as
`["path/inside/repo/tool.exe"]`, then tool won't be found if `jj fix` is
run from a subdirectory of the workspace.
There doesn't seem to be a good way to change this behavior, nor does it
seem easy to convert `program` into an absolute path because
`["tool.exe"]` could refer either to a file on the PATH or a file
committed at the root of the repository.
So, we add a new variable `$root` that can be used in this situation.
Workspace-relative tools on Windows should be defined using this
variable:
```toml
# Tools on the PATH
command = ["tool.exe"]
# Workspace-relative tools
command = ["$root/tool.exe"]
command = ["$root/nested/dir/tool.exe"]
```
On Unix, the command is found relative to the working directory of the
child process, so this isn't an issue.
Fixes#7144
I was initially planning to try adding an `nth` keyword argument to
`parents()` instead of adding `first_parent()`, and I noticed that based
on the current style, it would have been shown as one of the following
in the revset documentation:
* `parents(x[, depth[, [nth=]index]])`
* `parents(x[, depth][, [nth=]index])`
These both seem difficult to read to me, so I'm proposing changing the
style to something more like this:
* `parents(x, [depth], [[nth=]index])`
I also added a brief section explaining the syntax in case it isn't
immediately obvious what the square brackets mean.
I think this can be useful in CLI tests. I noticed there are lots of "jj file
list" calls in https://github.com/jj-vcs/jj/pull/6141 which could be combined
with "jj log" outputs.
This adds a version of the `bisect()` revset that simply takes the
midpoint of the input set when iterated over. That's correct in linear
history and probably usually good enough in non-linear history too. We
can improve it later. I think it's valuable to have this building
block even in an imperfect state.
Since we already have globset in transitive dependencies, this change helps
reduce the amount of dependencies. Another reason is that globset provides a
function to convert glob to regex. This is nice because we use globs to match
against strings or internal repository paths instead of platform-native paths.
The GlobPattern wrapper is boxed because globset::Glob type is relatively big.
Not setting `diff-args` is equivalent to `diff-args=["$left",
"$right"]`, which I also documented here.
I couldn't decide whether the new error should be part of
`DiffRenderError`, `DiffGenerateError`, or `MergeToolError`. Since the
treatment of diff formatters is already very different from other merge
tools, I just made it a CommandError for now.
Add a parents() method for `Operation` template objects, copied from the
implementation for `Commit`s.
The test case added in test_operations.rs was heavily inspired by
test_commit_templates.rs:test_log_parents().
Fixes#6979
This was requested by @lilyball on Discord. I still think we should create a blog longterm
so we can announce stuff and run surveys, but this small step won't block it.
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
As we've discussed on Discord, the community would prefer the
community leaders to be people who are actively involved in the
community. Vamsi hasn't been involved lately, and Isaac has offered to
take on the role. Thanks, both!
We still get many questions about the difference between `..` and
`::`. It turns out we didn't have an example of the typical case of
using `..` to find commits on a feature branch compared to the main
branch. This patch adds such an example.
It's surprising that a symbol expression may be resolved to multiple revisions,
and that's one of the reason we require all: modifier in some places. Let's make
a symbol resolution fail in that case so we can deprecate the all: syntax.
The new error hints are a bit less informative, but I don't want to implement
ad-hoc formatting for resolve_some_revsets_default_single(). The user will have
to review the graph anyway in order to resolve divergence/conflicts.
Closes#5632
