If `--to` is going to become a required argument, it should
have a short alias as it will be used quite frequently.
Given that `--to` has a short alias it only makes sense to
allow `-f` for `--from` as this is consistent with other
commands and nothing makes this particular command special.
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.
I think this will help implement sorting options. Untracked remote bookmarks
should be sorted independently, whereas tracked remote bookmarks should always
be listed after the associated local bookmarks.
Some of these will be called from "jj bookmark list". The template RefName type
is useful as an abstract local/remote ref object. Maybe it should be renamed to
RefEntry or CommitRef.
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`.
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.
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.
