The usage line originally showed `--from <REVSETS>|NAMES`, which was confusing as it
could be parsed as `--from (<REVSETS> or NAMES)`, rather than the correct `(--from
<REVSETS>) or NAMES`.
The order of the two arguments are now swapped, so that Clap displays it as
`NAMES|--from <REVSETS>` instead. Using bookmark names as the move targets should be
more common anyway. This is also consistent with the order in which the two arguments
are described in the command's doc comment.
the feature reused as much as possible of the `jj rebase` code, with
minimum modifications, in order to avoid reimplementing or complexifying
the rebase code.
It leads to some cases where some commits may be rewritten twice.
For example:
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file1
│ A file2
◆ zzzzzzzz root()
❯ jj split -r u -A m -m file1 file1
Rebased 3 descendant commits
First part: ulpvupsv aaf064bc file1
Second part: uttlrpzl 0d4358c2 file1&2
Working copy (@) now at: ylrkuwto 60d905c5 (empty) (no description set)
Parent commit (@-) : qsorlqym 8cfbe2d8 file4
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ ulpvupsv file1
│ A file1
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
◆ zzzzzzzz root()
There is an intermediate state created as
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
○ ulpvupsv file1
│ A file1
◆ zzzzzzzz root()
where the commits in `uttlrpzl::` have been rewritten, then `ulpvupsv`
is moved, effectively rewriting the commits in `ulpvupsv::`.
The number of user visible rewritten commits is accurately reported.
`jj split --parallel` is still done as a special case: implementing
it with the rebase code would put the first commits on the right
branch.
In parts of the description that are not about `-d` specifically, we
should not say "onto the destination". The message we print at the end
also says "onto destination". This updates both places to use "to"
instead of "onto".
The former wording of "With the `-r` option, which is the default" is
confusing, and made redundant by the clarifications within the
option-level documentation.
The former wording of "[w]ith the `-r` option, which is the default..." is
a bit confusing. This change brings `jj diff`'s documentation more in
line with the other commands with similar semantics, such as `jj rebase`.
The command has displayed all parents and the diff summary from the
merged parents since 48c44344bf (2022-12-04) but it still says that
it only cares about the first commit. This patch finally fixes that.
to set the message on the first commit, where the selected
changes are going. The commit with the remaining changes
keeps the original description.
With this option it becomes possible to use split in a fully
non-interactive way, in combination with the filset feature.
It also makes jj split more consistent with other commands
like squash, commit or new.
This allows the customization of the duplicated commit descriptions.
An ideal use case for this is emulating `git cherry-pick -x`, as
illustrated in the tests.
AFAICT, this option was needed when we're going to abandon hundreds of commits.
However, I typically notice that I had to use --summary to suppress the output
after the fact. Since the list is now truncated up to 10 commits, I don't think
the --summary flag is useful anymore. This patch also removes the special case
for 1 item, which existed primarily for overriding --summary.
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.
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).
I'm thinking of adding RefName(str) and RemoteName(str) newtypes, and the
templater type name would conflict with that. Since the templater RefName type
is basically a (name, target) pair, I think it should be called a "Ref", and I
added "Commit" prefix for disambiguation.
This isn't a breaking change since template type names only appear in docs and
error messages.
Adds a `templates.config.list` config option to control whether the
detailed list is shown or not.
The `builtin_config_list_detailed` template adds the config origin to
the end of the line for each config value in the list. Options coming
from files will show the file path.
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.
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>
The output of `jj unsign` is based on that of `jj abandon`.
We output warnings when unsigning commits, which are not authored by the
user. This is encouraging to use `jj undo`, in case one unintentionally
drops signatures of others.
---
Co-authored-by: julienvincent <m@julienvincent.io>
Co-authored-by: necauqua <him@necauq.ua>
We always sign commits. This means commits, which are already signed,
will be resigned. While this is cumbersome for people using hardware
devices for signatures, we cannot reliably check if a commit is already
signed at the moment (see https://github.com/jj-vcs/jj/issues/5786).
We output warnings when signing commits, which are not authored by the
user. This is encouraging to use `jj undo`, in case one unintentionally
signs commits of others.
The output of `jj sign` is based on that of `jj abandon`.
---
Co-authored-by: julienvincent <m@julienvincent.io>
Co-authored-by: necauqua <him@necauq.ua>
Forgetting remote bookmarks can lead to surprising behavior since it
causes the repo state to become out-of-sync with the remote until the
next `jj git fetch`. Untracking the bookmarks should be a simpler and
more intuitive default behavior. The old behavior is still available
with the `--include-remotes` flag.
I also changed the displayed number of forgotten branches. Previously
when forgetting "bookmark", "bookmark@remote", and "bookmark@git" it
would display `Forgot 1 bookmarks`, but I think this would be confusing
with the new flag since the user might think that `--include-remotes`
didn't work. Now it shows separate `Forgot N local bookmarks` and
`Forgot M remote bookmarks` messages when applicable.
Allows:
* self.commit()
* self.line_number()
* self.first_line_in_hunk()
Certain pagers (like `delta`), when used for `git blame`, only show the
commit information for the first line in a hunk. This would be a nice
addition to `jj file annotate`.
`jj file annotate` already uses a template to control the rendering of
commit information --- `templates.annotate_commit_summary`. Instead of
a custom CLI flag, the tools necessary to do this should be available in
the template language.
If `1 % 2` or `1.is_even()` was available in the template language, this
would also allow alternating colors (using `raw_escape_sequence`).
Example:
```toml
[templates]
# only show commit info for the first line of each hunk
annotate_commit_summary = '''
if(first_line_in_hunk,
show_commit_info(commit),
pad_end(20, " "),
)
'''
```
With this change a warning is shown if the user does not explicitly specify the target revision, but the behavior is unchanged (it still defaults to the working copy).
In the future the warning will be turned into an error. In other words, it will be required to specify target revision.
The bulk of the changes here are to prepare tests for the upcoming change, to make the transition easier.
For additional details please see:
* https://github.com/jj-vcs/jj/issues/5374
* https://github.com/jj-vcs/jj/discussions/5363
