I think this makes more sense because WorkspaceId is currently a human-readable
name. In error/status messages, workspace names are now printed in revset
syntax.
New WorkspaceId types do not implement Default. It would be weird if string-like
type had non-empty Default::default(). The DEFAULT constant is provided instead.
This allows callers to mutate RevsetParseContext if needed.
RevsetParseContext was changed to an opaque struct at 4e0abf06317f "revset: make
RevsetParseContext opaque." I think the intent there was to hide implementation
details from revset extension functions. This is now achieved by opaque
LoweringContext.
Another reason of this change is that aliases_map is no longer needed when
transforming AST to UserRevsetExpression.
I tried to minimize this patch, but it seemed rather complicated than porting
most callers all at once. Remote management functions in git.rs are unchanged.
They'll be ported separately.
With this change, many non-template bookmark/remote name outputs should be
rendered in revset syntax.
In colocated repos, we set up the Git index to make `git diff` closely
match `jj diff`. However, `git diff` will not include new files. We're
long talked about using the `git add --intent-to-add` feature to make
the match closer. This patch implements that. It does so both after
updating the working copy and after snapshotting. After updating the
working copy, the new file in the working-copy commit (compared to the
parent(s)) are marked as intent-to-add. After snapshotting, newly
snapshotted files are marked as intent-to-add, and deleted ones that
were previously marked as intent-to-add are removed from the index.
Closes#6122
I have no immediate plan, but I think we can make "jj git export" show exported
refs. The FailedRefExport type is replaced with a plain tuple since we have a
named type wrapping (symbol, reason) pairs now.
I usually don't read these messages carefully, and the red "(conflict)" label
looked scary. Suppose we don't have to take further action on resolved commits,
I don't think we need to print commit summary for each resolved commit.
The choice of the upper limit is arbitrary. We use 5 in "multiple revisions"
error, but I feel 5 would be too small for "jj absorb", where the stack of
mutable commits may be ~10, but wouldn't likely be ~100s.
This adds a revert command which is similar to backout, but adds the
`--destination`, `--insert-after`, and `--insert-before` optoins to
customize the location of the new reverted commits.
`jj backout` will subsequently be deprecated.
Closes#5688.
The current behaviour means (transitively) dependent crates' debug logs end up
in our logs when `--debug` is active.
The biggest offender here is `globset`, imported from the `ignore
crate`. These logs are extremely noisy and mostly irrelevant from our usecase.
This commit changes this behaviour to whitelist `jj` related debug logs,
while allowing more debugging to come from env vars
Multiple user configs are now supported and are loaded in the following precedence order:
- `$HOME/.jjconfig.toml`
- `$XDG_CONFIG_HOME/jj/config.toml`
- `$XDG_CONFIG_HOME/jj/conf.d/*.toml`
Which removes the need to set `JJ_CONFIG` for a multi-file approach.
Later files override earlier files and the `JJ_CONFIG` environment
variable can be used to override the default paths.
The `JJ_CONFIG` environment variable can now contain multiple paths separated
by a colon (or semicolon on Windows).
We could replace clap's "SuggestedSubcommand" instead of removing it,
but then the user might not notice that this is a custom suggestion and
not pay enough attention to it.
This uses the just-released https://github.com/clap-rs/clap/pull/5941.
I'm going to reimplement git_ref_filter to process translated remote bookmark
names, and "git" remote will mean the local Git-tracking remote there. The
reserved remote name is checked prior to filtering because refs in that remote
cannot be represented as remote symbols.
I originally implemented the error handling the other way because we didn't
have a machinery to report partial import failure. Now we have stats, it's
easy to report skipped ref names.
Also resolves one TODO made possible by the new MSRV
Most of this was done by enabling the lint forbidding `allow` directives
using `cargo cranky`, running `cargo cranky --workspace
--all-featuers --fix`, and fixing up the result.
The CI seems to correctly use rustc 1.84.1 (and not 1.84.0) with this.
For reference, we last updated the MSRV to 1.76 in 5b517b5. According to
https://releases.rs/docs/1.76.0/, this was when it barely became stable.
`flake.nix` seems to be using a nightly toolchain now, so it seems there
is no need to update the version there.
The more precise clippy command used was:
cargo clippy --workspace --all-targets --fix
The main goal here is so that a completely new user that types in `jj
init` or `jj clone` gets a pointer to the correct command needed to try
out `jj`.
This will be used to compute the location to place commits from the
`--destination`, `--insert-after`, and `--insert-before` options. This
is used across the `new`, `duplicate`, and `rebase` commands, and can be
used for further commands as well.
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.
