It only occurred to me after I rebuilt jj and actually had to run the command
that we should probably recommend a change to the user config instead of the
repo config.
#3419
Currently, `jj split` moves bookmarks from the target revision to the second
revision created by the split. Since the first revision inherits the change id
of the target revision, moving the bookmarks to the first revision is less
surprising (i.e. the bookmarks stay with the change id). This no-implicit-move
behavior also aligns with how `jj abandon` drops bookmarks instead of moving
them to the parent revision.
Two releases from now, `jj split` will no longer move bookmarks to the second
revision created by the split. Instead, local bookmarks associated with the
target revision will move to the first revision created by the split (which
inherits the target revision's change id). You can opt out of this change by
setting `split.legacy-bookmark-behavior = true`, but this will likely be
removed in a future release. You can also try the new behavior now by setting
`split.legacy-bookmark-behavior = false`.
Users who have not opted into the new behavior via the config setting will see
a warning when they run `jj split` informing them about the change. The default
behavior be changed in the future.
The `jj split` tests for bookmarks are updated to run in all three configurations:
- Config setting enabled
- Config setting disabled
- Config setting unset
#3419
The fix settings weren't indented consistent with the rest of the settings,
causing them to appear in the redacted snapshot in the test_util_config_schema
test.
In addition to a single string, the `ui.editor` and `ui.diff.tool` options also
allow arrays of strings. `ui.pager` allows arrays of strings as well as a nested
table describing both the command and the environment.
Update config-schema.json to allow all of these types of values.
Fixes#5617
We are planning to add a config option that controls how bookmarks and change
ids move during `jj split` based on feedback in https://github.com/jj-vcs/jj/pull/5618.
I think the tests will be more readable after the config option is added if we
move the bookmark testing to its own test.
#3419
"$comment" is not officially supported by draft-4, but it is in newer
drafts, and JSON schema readers are supposed to skip fields that
are not known to them.
This makes the schema a bit less smart, but there's a good chance
`taplo` could not use "propertyNames" anyway because that comes
from a newer version of the schema than `taplo` officially supports
(see the child of this commit).
Fixes#5607
With this change a warning is shown if the user does not explicitly specify the target revision, but the behavior is unchanged (it still defaults to the working copy).
In the future the warning will be turned into an error. In other words, it will be required to specify target revision.
The bulk of the changes here are to prepare tests for the upcoming change, to make the transition easier.
For additional details please see:
* https://github.com/jj-vcs/jj/issues/5374
* https://github.com/jj-vcs/jj/discussions/5363
Given the previously‐stated intention of making this default
for the 0.27 release, prepare for that decision ahead of time by
enabling subprocessing by default on trunk. This will help surface
any regressions and workflow incompatibilities and therefore give
us more information to decide whether to keep or revert this commit,
without inconveniencing any users who haven’t already opted in to
the bleeding edge.
Please feel free to revert without hesitation if any major issues
arise; this is not intended as a strong commitment to enable this
option for the next stable release if it turns out to not be ready. In
that case, it’s better that we learn that early on in the cycle,
rather than having to revert at the last minute or, worse, cutting
a stable release that we later find contains a serious regression.
When a commit is split, the second commit produced by the split becomes the
working copy commit for all workspaces whose working copy commit was the target
of the split.
This commit adds two tests for this behavior:
1. Split a commit which is the working copy commit for two workspaces.
2. Split a commit which is the working copy commit for only one of the two
workspaces.
These tests check that the working copy commits for the workspaces are updated
correctly. Both parallel and non-parallel splits are tested.
there are many ways to implement `heads` for your custom backend:
one involves calling `self.evaluate_revset` with a proper revset.
However, it can return an error, but `heads` does not allow it.
In our implementation of the index backend we do exactly the above
and we ended up with several unwraps which we are trying to avoid
as it could potentially crash our prod jobs.
P.S. The same logic applies to many methods in this trait, but I am doing one at a time.
One common issue that users run into with `jj undo` is that they expect
it to behave like an "undo stack", in which every consecutive `jj undo`
execution moves the current state further back in history. This is
(currently) an incorrect intuition - running multiple `jj undo` commands
back-to-back will only result in the previous non-undo change being
reverted, then un-reverted, then reverted, and so on.
This change adds a hint when the user runs `jj undo` multiple times
consecutively, suggesting that they may be looking for `jj op restore`,
which allows them to revert the whole state of the repository back to
a previous snapshot.
If an ellipsis arg is given to the truncate_* template functions, append (or
prepend) the ellipsis when the template content is truncated to fit the maximum
width.
Fixes#5085.
Since we need to scan directory entries recursively in order to detect new
untracked paths, it doesn't make sense to reuse the .gitignore code path.
This change means all untracked file paths are listed in "jj status" even if
the whole directory is untracked. It might be a bit verbose, but should be
okay. Directories like node_modules should be excluded by .gitignore, not by
auto-track pattern.
Fixes#5389
In the future, we could consider adding a few more
special configs, e.g. `:pagerenv` that strictly uses
the `PAGER` environment variable, and `:unix` that
mimics Git's algorithm of trying `PAGER`, defaulting
to `less`, and setting `LESS`.
I originally considered adding `stats() -> DiffStats` which returns an
unprintable object, with deprecation of `.stat(width)` in favor of
`.stats().<method_to_render>(width)`. However, I couldn't find a good name for
the rendering function. This patch instead made the width parameter optional. I
think that's good because template language doesn't have to be overly strict.
Closes#4154
This will help write template based on diff.stat() result. #4154
show_diff_stats() isn't reimplemented as DiffStats method because I think
DiffStats can be moved to jj-lib.
