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.
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
Typo in signing.behavior shouldn't be ignored.
The idea is the same as [user] and [operation] tables. It's easier if all
parameters needed to create a commit is parsed by UserSettings constructor.
Another option is to make repo.start_transaction() fail on config error.
The gix feature "blocking-network-client" was configured in cd6141693
(cli/tests: add gitoxide helpers, 2025-02-03) most likely because
we needed to clone using gix in tests, but 071e724c1 (cli/tests:
move test_git_colocated_fetch_deleted_or_moved_bookmark to gitoxide,
2025-02-25) changed the test to clone by subprocessing out to system git
(not by using gitoxide, as a cursory read of the commit description may
indicate), meaning that we no longer need that feature.
Therefore, remove that feature.
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
Clearing a sign key would require calling `set_sign_key(None)`, which
makes the API slightly awkward.
Instead, we introduce `clear_sign_key()` and make `set_sign_key()` only
accept a `String`. This makes clearing the sign key explicit.
Co-Authored-By: Yuya Nishihara <yuya@tcha.org>
This will probably mitigate problems of concurrent updates. If two concurrent
processes tried to import + reset HEAD, one of them should fail.
Closes#3754
I'm going to fix some CLI outputs to print remote symbols in revset syntax, and
it's easier if the view API took/returned type that represents a ref name.
.as_ref() and .to_owned() are implemented as non-trait methods because
RemoteRefSymbol can't be a true reference type. I think it's similar to
Option::as_ref(). I couldn't find any std examples of non-trait .to_owned(),
though.
This means that watchman is partially disabled until the user cleans up
untracked files. This isn't nice, but should be better than hiding untracked
files forever.
Fixes#5728Fixes#5602
This fixes real dependency cycle that would expose slightly different versions
of jj_lib types to unit tests, one from super::* and another from testutils::*.
The testutils dependency can be removed by splitting lib/tests to a separate
crate.
These helpers are going to be needed to port the git2 code in the lib
tests to gitoxide. Since the cli tests already depend on testutils, this
helps with avoiding duplicating the code
Although this behaviour is accepted by git, it's a degenerate case.
Especially because we implicitely rely on being able to parse out the
remote from the refname (i.e., `refs/remotes/<remote>/<branch>`).
Branches can have forward slashes, but if remotes can also have them,
parsing the refname becomes ambiguous, and a pain. Especially because it
would be totally legal to have a branch "c" on remote "a/b" and a branch
"b" on remote "a".
Fixes#5731
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.
This was discussed in the Discord a while ago, and this is the logical and consistent
conclusion. Implementing it as such makes it consistent with both `jj edit` and `jj new`
which make hidden commits such as predecessors visible.
This actually was Martins work, I just added the tests.
Co-Authored-by: martinvonz <martinvonz@google.com>
`gix::Repository` instances are larger than 1KB on 64-bit machines. This
makes Clippy warn about an unbalance between variants of `GitFetchImpl`:
the `Git2` variant requires 8 bytes, while the `Subprocess` variant
requires 1128 bytes.
Boxing the `gix::Repository` makes `GitFetchImpl` instances smaller, as
well as the other structs embedding them such as `GitFetch`.
