There have been a number of users confused about why
their commits are immutable, or what to do about it, ex.
[https://github.com/jj-vcs/jj/discussions/5659].
Separately, I feel that the cli is too quick to suggest
`--ignore-immutable`, without context of the consequences. A new user
could see that the command is failing, see a helpful hint to make it not
fail, apply it and move on. This has wildly different consequences, from
`jj squash --into someone_elses_branch@origin` rewriting a single commit,
to `jj edit 'root()+'` rewriting your entire history.
This commit changes the immutable hint by doing the following:
* Adds a short description of what immutable commits are used for, and a
link to the relevant docs, to the hint message.
* Shows the number of immutable commits that would be rewritten if
the operation had succeeded.
* Removes the suggestion to use `--ignore-immutable`.
Aliases and `ui.default-command` are loaded before `--config` and
`--config-file` arguments are parsed (#5282).
There is supposed to be a warning when the result of these arguments
would change the parsed args: #5286.
However, that warning was not being printed if the arguments failed to
parse due to an unrecognized subcommand. Example:
```bash
# correct:
$ jj --config ui.default-command=nonsense
Warning: Command aliases cannot be loaded from -R/--repository path or --config/--config-file arguments.
# previous, confusing:
$ jj --config aliases.some-alias=nonsense some-alias
error: unrecognized subcommand 'some-alias'
# now:
$ jj --config aliases.some-alias=nonsense some-alias
Warning: Command aliases cannot be loaded from -R/--repository path or --config/--config-file arguments.
error: unrecognized subcommand 'some-alias'
```
Move the `track` specific logic to track.rs, let print_snapshot_stats
handle just the default case.
Previously print_snapshot_stats would get called twice and could warn
twice about a file (if that file was both in the auto-track fileset as
well as in the fileset passed to `jj file track`), so now we merge the
snapshot stats and display appropriate hints for each file.
Snapshot stats were automatically printed when calling
`WorkspaceCommandHelper::snapshot_working_copy`. This has been moved up
the call chain to allow more choice in when to actually print stats.
These functions used to trigger printing of the snapshot stats via
(direct or indirect) calls to `snapshot_working_copy`:
- CommandHelper::workspace_helper_with_stats
- CommandHelper::recover_stale_working_copy
- WorkspaceCommandHelper::maybe_snapshot_impl
This means we can now chose not to print the snapshot stats if we know
we will perform another snapshot operation during the same command, to
reduce the number of warnings and hints shown to the user.
Calling `workspace_helper`, or `maybe_snapshot` instead of
`workspace_helper_with_stats` and `maybe_snapshot_impl` still prints
stats automatically.
In the case where the user has set `snapshot.auto-track` to something
other than `all()`, running `jj st` with a higher file size set just for
that command will not actually fix the user's problem, `jj file track`
needs to be called instead.
Some working-copy implementations, like the Google CitC one, may want
to update the VFS's state even if the tree didn't change. In
particular, when updating between two commits with the same tree but
different mainline base, we want to update the base commit. Otherwise
a future snapshot, which we do relative to the mainline commit, may
notice an incorrect set of changed file.
When updating the working copy results in no changes, we currently
return `None` from `cli_util::update_working_copy()`. However, a no-op
update is still an update, so I think it makes more sense to always
return a `CheckoutStats`. We already skip printing stats if they're
zero.
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.
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.
Now `jj --config ui.con<TAB><TAB>` will autocomplete
```
ui.conflict-marker-style=diff
ui.conflict-marker-style=snapshot
ui.conflict-marker-style=git
```
Booleans are completed as `false`, `true`, the remaining types are left
without completions.
the trailing `=` is especially nice to have because otherwise fish will
complete the suggestion and insert a space before the cursor.
With the `=`, `jj config --config ui.pagin<TAB>never` works.
UserSettings will be obtained from there. If operation template supported
"self.repo() -> Repo" method, RepoLoader would be needed. It's equivalent to
Repo in CommitTemplateLanguage.
The list of migration rules is managed by CliRunner. I don't know if that's
needed, but in theory, an extension may insert migration rules as well as
default config layers.
Migration could be handled by ConfigEnv::resolve_config(), but it seemed rather
complicated because Vec<ConfigMigrationRule> cannot be cloned, and the scope of
these variables are a bit different.
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>
This backs out commit 0de36918e4c020e0e54816f29c47cb57cc9cfbf5. Documentation,
tests, and comments are updated accordingly. I also add ConfigTableLike type
alias as we decided to abstract table-like items away.
Closes#5255
This will give us more fine-grained control over what files we put in
the index, allowing us to create conflicted index states. We also still
need to use git2 to clean up the merge/rebase state, since gix doesn't
have any function for this currently.
This ensures that WorkspaceCommandHelper created for initialized/cloned repo
refers to the settings object for that repo, not the settings loaded for the
cwd repo.
I also removed WorkspaceCommandEnvironment::settings() because it doesn't own
a workspace object. It's implementation detail that the env object holds a
copy of workspace.settings(), and the caller should be accessible to the
workspace object.
This patch doesn't fix DiffEditor::edit() API, which is fundamentally broken
if matcher argument is specified. I'm not sure if the builtin behavior is
correct or not. Suppose we add "jj diffedit FILESETS..", it would probably make
sense to leave unmatched paths unmodified because it is the command to edit the
destination (or right) tree. This is the edit_diff_external() behavior.
Fixes#5252
The idea is the same as diff_editor()/selector() API. This object will be passed
in to edit_*description() functions in place of (repo_path, settings) pair.
"ui.editor" isn't specific to editing commit descriptions, but it's mainly used
for that purpose. So I put the wrapper type in description_util.rs.
These paths may be printed, compared with user inputs, or passed to external
programs. It's probably better to avoid unusual "\\?\C:\" paths on Windows.
Fixes#5143
This patch moves max_new_file_size() and conflict_marker_style() to CLI, but
there isn't a clear boundary whether the configuration should be managed by
UserSettings or not. I decided to move them to CLI just because we can eliminate
.optional() handling. The default parameters are defined in config/misc.toml.
This is an alternative way to achieve includeIf of Git without adding "include"
directive. Conditional include (or include in general) is a bit trickier to
implement than loading all files and filtering the contents.
Closes#616
The next patch will introduce the resolution stage of conditional tables.
Since it wasn't easy to detect misuse of "raw" StackedConfig, I added a thin
newtype.
I'm going to add config post-processing stage in order to enable config
variables conditionally, and handle/parse_early_args() doesn't have enough
information to evaluate the condition.
The deprecation warning could be emitted by parse_early_args(), but it's
probably better to print it after --color option is applied.
