It would be good to include the word "divergent" in the log when a
change is divergent, since users are often unsure what's happening when
they see a divergent change, and giving them a term to search for would
be helpful. However, I don't think it looks good to put this label next
to the change ID itself if both are the same color, since it ends up
being hard to distinguish from the change offset at a glance. Also,
putting the label next to the change ID also messes up the alignment of
fields in the log. Therefore, I think it looks better to put the
"divergent" label at the end of the line.
Since divergence and hidden commits are similar, it makes sense for both
labels to be in the same place, so I also moved the hidden label to the
end for consistency.
One downside is that the labels are less obviously connected with the
change ID itself due to them being farther apart. I think this could be
fine, since they are still visually connected by being the same color.
The goal of this change is to unify defaults of string patterns in revsets and
command arguments. Glob is a good default because it's largely the same as exact
matching, and we can easily express substring patterns with globs.
The hint for "jj git fetch -b<glob>" is deleted since exact:<glob> is now
required in order to trigger the error.
This patch also updates help of clone/fetch --branch patterns. Glob and operator
support in refspecs is limited.
Running "cargo insta test --workspace", results in numerous warnings:
Snapshot test passes but the existing value is in a legacy format.
Please run `cargo insta test --force-update-snapshots` to update to
a newer format.
This commit is the result of running the suggested command.
As a follow-up to #8115, this moves all references in the codebase to use the new website.
I didn't update the older CHANGELOG entries because I figured they're intended
to be immutable.
The character used for splitting the argument from its description /
help text was incorrect. In the template syntax used to obtain those
information, a tab ('\t') was used, while the parsing split the line
base on the pattern ": ".
The result was that the suggested argument for completion was
systematically incorrect, as the help text is systematically added, with
a default to "(no description set)".
The test was also incorrect, the expected pattern, for each line, was
'<value>\t<description>' since <value> was actually
`<value>\t<description>` the test was badly configured to expect
`<value>\t<description>\t'.
Fixes#7024.
On Windows, where the native path separator is `\`, either `/` or `\`
can be used (at least in PowerShell which's supported by clap-complete).
To ensure that the input string indeed prefixes the candidate paths,
we now normalize both to use forward slashes. The remainder which is
spliced onto the input string will thus use forward slashes on all
platforms. That way, the completion is now also usable in git-bash.exe
(Git for Windows with `COMPLETE=bash`). When using dynamic completion
with PowerShell, the completion results are still valid, as PowerShell
can tolerate forward slashes.
Fixes#6861.
In the original `dir_prefix_from` function, `current` might not be a
prefix of the (normal) completion candidate `path` if `current` itself
is non-normal. In case `current` is longer than the candidate `path`,
the code previously panicked. The tests have been extended to trigger
this panic.
This commit rewrites how the file-path completion is determined from
a potentially non-normal `current_prefix`. The panic is avoided by
using `strip_prefix()` instead of direct slicing. The basic idea is to
normalize the `current_prefix` first to obtain an actual prefix of the
(normal) `path`. The remainder can then be spliced onto the original
`current_prefix` to form a non-normalized completion path that is
prefixed by `current_prefix`, allowing the shell to accept it.
This requires a different API for the helper than what `dir_prefix_from`
provided. The latter assumed that when `None` was returned, `path` could
be completed as-is; a `Some` value indicated a partial completion of
`path` to the next directory. This is no longer sufficient as we need to
potentially return a different, non-normal path in either case.
Since we want to ignore the `mode` for directory completions, the
helper must also return the type of completion (partial/directory
or full/file). To avoid propagating this information, I instead
pass the `mode` into the helper and have it return finished
`CompletionCandidate`s. This arguably yields cleaner code on the caller
side, too.
This patch doesn't add builtin_evolog_redacted template because I'm not sure if
we want to collect evolution log for debugging purpose. The redacted template
can be added later if needed.
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
I don't think the original implementation handles sorting and filtering of the
renamed source paths correctly, so I've added explicit .sort() at the end.
Fixes#6922
There are two major goals:
1. garbage-collect predecessor commits referenced by immutable commits.
2. show operations alongside predecessors in "jj evolog".
The predecessors field will be removed from the Commit object. Maybe we can
also remove (writer side of) the extras table from GitBackend.
"jj evolog" will traverse the operation history to build an evolution
graph. This will be slower than the current implementation, but it seems
tolerable for mid-size repository stored in a local disk.
(when the page cache is warm)
% time jj op log -T'"."' --no-graph | wc -c
50459
jj op log -T'"."' --no-graph 0.12s user 0.31s system 103% cpu 0.418 total
Suppose we're interested in recent modifications, the traversal can often be
terminate early. I also have an idea for indexing originating operations.
https://github.com/jj-vcs/jj/pull/6405
For old operations which didn't record predecessors, "jj evolog" will fall back
to commit.predecessor_ids(). That's why commit_predecessors is Option<_>.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
This also adds a test case for the completion of arguments following
multi-argument aliases, to cover the bug reported in issue #5377.
The default command is like a special kind of alias, one which is
expanded from zero tokens. Consequently, it also triggers the bug
#5377 on bash/zsh, even if the `default-command` is just a single token.
The fix is along the lines sketched out by the "TODO" comment. Bash and
Zsh don't behave identical, so the padding ([""]) still needs to be
applied (and removed) conditionally in a disciplined manner.
The completion mechanism works differently in different shells:
For example, when the command line `jj aaa bb ccc` is completed at the
end of the `bb` token, bash and zsh pass the completer the whole line
`-- jj aaa bb ccc` and an index of 2 which refers to the `bb` token;
they are then expected to complete `bb`. Meanwhile, fish and Powershell
only pass the command up to the completion point, so `-- jj aaa bb`;
the completer is always expected to complete the last token. In all
cases, the shell ultimately decides what to do with the completions,
e.g. to complete up to a common prefix (bash), to show an interactive
picker (zsh, fish), or to insert the completion if it is the only one
(all shells). Remaining tokens (`ccc`) are also always appended by the
shell and not part of the completion.
While this is mostly handled by the clap_complete crate, we do expand
aliases and present clap_complete with a fake view of the real command
line, thereby reaching into its internals by wrapping the interface
between the completion shell script that is provided by clap_complete
and its Rust code in `CommandEnv::try_complete()`. If we get this wrong,
completion might yield unexpected results, so it is worth testing
completion for both flavors of shells whenever aliases are potentially
in the mix.
To avoid redundancy, the shell-specific invocation of `jj` is factored
into a `complete_at()` function of the test fixture. The `test-case`
crate is then used to instantiate each test case for different values of
clap_complete's `Shell` enum.
filter
bash/zsh specific behavior
move impl
This makes it easier to override just the default description without
having copy the whole default template (and having to keep it up to
date with new versions).
With this template, a 'git format-patch' compatible
email message can be generated using something like:
jj show --git --template git_format_patch_email_headers <rev>
Previously, the completions suggested the literal string:
`{f_not_yet_renamed => f_renamed}`. Instead, the old and new file names
should be completed separately.
Previously, the "renamed" file wasn't deleted at its old location, so it
wasn't renamed at all. Correcting this reveals a bug in the completions
of renamed paths. The completions suggest the literal string:
`{f_not_yet_renamed => f_renamed}`. Instead, the old and new file names
should be completed separately.
This moves the default template to `builtin_draft_commit_description` and
points `draft_commit_description` to it. This makes it easier to override
the template while still being able to refer to the default.
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.
