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
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>
There have been a number of users confused about why
their commits are immutable, or what to do about it, ex.
[https://github.com/jj-vcs/jj/discussions/5659].
Separately, I feel that the cli is too quick to suggest
`--ignore-immutable`, without context of the consequences. A new user
could see that the command is failing, see a helpful hint to make it not
fail, apply it and move on. This has wildly different consequences, from
`jj squash --into someone_elses_branch@origin` rewriting a single commit,
to `jj edit 'root()+'` rewriting your entire history.
This commit changes the immutable hint by doing the following:
* Adds a short description of what immutable commits are used for, and a
link to the relevant docs, to the hint message.
* Shows the number of immutable commits that would be rewritten if
the operation had succeeded.
* Removes the suggestion to use `--ignore-immutable`.
Previously, tools invoked by `jj fix` did not have their
`.current_dir()` set, and would just run from whatever directory the
user was in.
Now, the tools will always be invoked from the same directory that
`jj root` gives.
As a motivating example, consider a configuration path that's always at
the workspace root:
```toml
[fix.tools.something]
# previous:
command = ["cmd", "--config", "$root/tool.toml"]
# ^^^^^^ not possible
# now:
command = ["cmd", "--config", "./tool.toml"]
# ^^ now, just use a relative path
```
Aliases and `ui.default-command` are loaded before `--config` and
`--config-file` arguments are parsed (#5282).
There is supposed to be a warning when the result of these arguments
would change the parsed args: #5286.
However, that warning was not being printed if the arguments failed to
parse due to an unrecognized subcommand. Example:
```bash
# correct:
$ jj --config ui.default-command=nonsense
Warning: Command aliases cannot be loaded from -R/--repository path or --config/--config-file arguments.
# previous, confusing:
$ jj --config aliases.some-alias=nonsense some-alias
error: unrecognized subcommand 'some-alias'
# now:
$ jj --config aliases.some-alias=nonsense some-alias
Warning: Command aliases cannot be loaded from -R/--repository path or --config/--config-file arguments.
error: unrecognized subcommand 'some-alias'
```
Move the `track` specific logic to track.rs, let print_snapshot_stats
handle just the default case.
Previously print_snapshot_stats would get called twice and could warn
twice about a file (if that file was both in the auto-track fileset as
well as in the fileset passed to `jj file track`), so now we merge the
snapshot stats and display appropriate hints for each file.
