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.
It's super common to pair test_env with repo_path.
Some of the tests still use absolute paths because it seemed rather confusing
to mix paths relative to the repo_root and to the env_root.
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.
I'm about to move the `create_commit()` helper to a common
place. However, this version of `create_commit()` is different from
the others in that it put a prefix of "descr_for_" in the
description. This patch removes that and instead updates the template
so it's still clear what's a description and what's a bookmark name.
This is hidden gem of a feature, especially in combination.
`JJ_CONFIG` being a directory allows loading multiple TOML config files.
`--when` can be used on the top level, which can lend itself to a much
cleaner config than `[[--scope]]` tables.
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.
The paste crate hasn't had a maintainer since Oct. 2024. We don't use it
directly, but it's used by ratatui, and there's no direct replacement for it
AFAIK.
Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
This is currently blocking PRs because ci fails:
```
error[unmaintained]: paste - no longer maintained
┌─ /github/workspace/Cargo.lock:262:1
│
262 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
│
├ ID: RUSTSEC-2024-0436
├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md)
that this project is not longer maintained as well as archived the repository
├ Announcement: https://github.com/dtolnay/paste
├ Solution: No safe upgrade is available!
├ paste v1.0.15
└── ratatui v0.29.0
└── scm-record v0.5.0
└── jj-cli v0.27.0
└── (dev) jj-cli v0.27.0 (*)
advisories FAILED
```
It's odd that "foo/bar" is tested earlier in push_branches() whereas "git" is
rejected by push_updates(). Suppose push_updates() is a low-level function to
push arbitrary refs without updating jj's repo view, it's probably okay to allow
unsupported remote name here.
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.
