ui.progress_output() doesn't borrow anything from &Ui, and there would be no
reason to extend the borrow. Write ops on Ui don't require mutable instance.
This change moves the code for prompting the user to select changes for the
first commit to a helper function. There are no functional changes.
Resulting from the discussion in https://github.com/jj-vcs/jj/pull/5828
we are planning to add several new flags (-B, -A, and -d) to jj split.
Since this may change how the user selects changes (i.e. they may select
changes to remove from the target commit, rather than what stays in the target
commit), I want to move the selection logic to a function to make the main
split function more readable.
This is part of a refactor of cmd_split in preparation for adding new -A, -B,
and -d arguments to control where the changes split from the target commit end
up.
The goal is to simplify the flow in the main cmd_split function and manage
complexity introduced by the new options. In this case, the raw arguments will
be parsed once at the beginning of the command in resolve_args, after which the
raw SplitArgs are no longer used.
The function is pretty simple now, but will evolve once the new arguments are
added.
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
It is not needed to gate `jj debug init-local` on an option now that the
command is no longer called `jj init`.
This also includes a separate fixup to #5845 in demos/
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`.
Now that we depend on the `git` executable being available for `jj git
fetch/push` tests, we might as well use it for `jj util gc` tests
too.
I also switched to using the Git backend in
`cli/tests/test_file_track_untrack_commands.rs`, which seemed to be
using the local backend for no good reason.
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.
The previous implementation of `new --insert-after` excluded children
that were ancestors of the new commit. This was done to avoid creating
cycles in the commit graph. However, this does not align with the
behavior of the `--insert-after` in the other commands, which explicitly
error if inserting a new commit after the given `--insert-after` commits
would create a cycle.
For consistency, and given that the desired behavior can be achieved
using by using `--insert-after` along with `--insert-before`, this
behavior is removed.
After system crash, file contents are often truncated or filled with zeros. If
a file was truncated to empty, it can be decoded successfully and we'll get
cryptic "is a directory" error because of an empty view ID. We should instead
report data corruption with the ID of the corrupted file.
#4423
The consensus about this change, if one ever existed, seems to have dissolved
into two cohorts, one which is happy with the change, and one which thinks we
should move both the bookmark and change id to the child commit instead of
leaving them on the parent.
We may decide to add flags to allow users to choose between the two behaviors,
but there are also other concerns such as where @ should go (parent or child).
Until we agree on a path forward it seems reasonable to delay the breaking
change by disabling it via the config option we added. I don't think it's
necessary to fully revert the code and new tests since we aren't announcing the
option.
#3419
This has bothered me for a while... It's useful to describe the target of the
split command as the "target commit", and it's a little confusing to have a
variable named "commit" in the code when we are dealing with several different
commits in the command.
I think this improves readability by being more precise.
When signing commits with `jj sign`, one might want to use a workflow
like:
```bash
jj fix && jj sign .. && jj git push
```
Making the default value for `-r`/`--revisions` configurable, will allow
such a workflow.
Co-Authored-By: Yuya Nishihara <yuya@tcha.org>
