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>
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
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.
Snapshot stats were automatically printed when calling
`WorkspaceCommandHelper::snapshot_working_copy`. This has been moved up
the call chain to allow more choice in when to actually print stats.
These functions used to trigger printing of the snapshot stats via
(direct or indirect) calls to `snapshot_working_copy`:
- CommandHelper::workspace_helper_with_stats
- CommandHelper::recover_stale_working_copy
- WorkspaceCommandHelper::maybe_snapshot_impl
This means we can now chose not to print the snapshot stats if we know
we will perform another snapshot operation during the same command, to
reduce the number of warnings and hints shown to the user.
Calling `workspace_helper`, or `maybe_snapshot` instead of
`workspace_helper_with_stats` and `maybe_snapshot_impl` still prints
stats automatically.
This should help prevent misuse of "jj bookmark set" with e.g. remote bookmark
name. A remote-looking bookmark can be created by quoting the name if needed.
This patch doesn't change the parsing of name patterns. For patterns, I think
it's better to add support for compound expressions (e.g. `glob:foo* & ~bar`)
rather than adding revset::parse_string_pattern(text) -> StringPattern.
Closes#5705
The "conflict" label is supposed to highlight "(conflict)" markers in commit
template. This patch just removes the label as we don't colorize the same
message in update_working_copy().
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
In the case where the user has set `snapshot.auto-track` to something
other than `all()`, running `jj st` with a higher file size set just for
that command will not actually fix the user's problem, `jj file track`
needs to be called instead.
Some working-copy implementations, like the Google CitC one, may want
to update the VFS's state even if the tree didn't change. In
particular, when updating between two commits with the same tree but
different mainline base, we want to update the base commit. Otherwise
a future snapshot, which we do relative to the mainline commit, may
notice an incorrect set of changed file.
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.
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.
The condition we were checking (which I suggested during review) is
very broken. It checks if the new view is equal to view before the
current operation, but that's supposed to always be true (except for
operation that update remote bookmarks). The reason the warning didn't
trigger all the time was that we did the comparison after calling
`merge_view()` but before calling `rebase_descendants()` (via
`tx.finish()`). The former only records commits as abandoned without
actually hiding them. However, because of [the hack][hack] in
`merge_view()` to make it work reasonably well in huge repos, every
undo operation at Google would print the warning.
This patch fixes the bug by checking if the to-be-undone operation is
an undo by comparing its view to its grandparent's view.
[hack]: ec6f8278fd/lib/src/repo.rs (L1693-L1708)
After even more discussion on Discord, we decided to use the new bookmark
behavior immediately and only print a warning during `jj split` if the user has
opted out of the new behavior using the `split.legacy-bookmark-behavior` config
setting.
The reasoning is that if the behavior change breaks someone's workflow or is
very disruptive, they are likely to check the changelog and learn about the
config option. For users that are not adversely impacted, printing a warning
that can only be silenced by changing their config is also disruptive.
#3419
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, " "),
)
'''
```
There's currently no way to tell what `jj fix` is doing. This adds some
traces such that `jj fix --debug` will at least tell you what's being
run and what it's exit code is, similar to other subprocessing code.
