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
"$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.
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.
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.
Total aadded/removed counts will be provided as DiffStats methods. This change
might result in slightly bad perf, but that wouldn't matter in practice.
Add a new pad_center function that centers content within a minimum
width. If an odd number of fill characters is required, the trailing
fill will be one character longer than the leading fill.
Fixes#5066.
With git.subprocess = true, it's more important to skip unneeded remote
operations. Each remote command may involve user intervention if authentication
requires manual step.
This change also means that the remote connection is no longer reused in git2
impl. I think the added cost is acceptable. The git2 impl will hopefully be
removed soon, and the remote branch name is needed only when cloning new repo.
E.g. when the user doesn't have the default command set, you don't want
to get
```
Warning: Cannot define an alias that overrides the built-in command 'log'
```
printed on every completion.
