We recently renamed `jj util mangen` to `jj install-manpages` without a
deprecation warning, as it was missed in the initial PR. Waleed then
fixed it in a follow-up, which led to a longer discussion in the Discord which revealed that
not everyone was aware of it and _what_ requires a warning based deprecation.
This initially categorizes the policy into user-visible UX changes and small
impact renames, like for a small usergroup like packagers and third-party dependencies.
If we have more hickups with users, this can be expanded.
In docs/templates.md, the Commit type and Operation type looked like:
`method() -> ReturnType`
rather than everything else, which looks like:
`.method() -> ReturnType`
This commit changes the Commit and Operation types to look more like the
rest of the documentation.
- Now computes the latest tag automatically in the first suggested command.
- Now excludes dependabot.
I used the command to generate the list of contributors in the v0.28.0 release commit.
This helps detect whether the last line is "JJ:" instruction or not. It seems
also nice that I don't have to insert newline to reflow the edited paragraph.
I think this makes more sense because WorkspaceId is currently a human-readable
name. In error/status messages, workspace names are now printed in revset
syntax.
New WorkspaceId types do not implement Default. It would be weird if string-like
type had non-empty Default::default(). The DEFAULT constant is provided instead.
In the diagram, E has parent B, and D has parents B and C, so the fork point of E and D
(the most downstream common ancestor of these commits) should be B rather than A.
To avoid redundant computation, users who run `COMPLETE=fish jj | source`
in their ~/.config/fish/config.fish should eventually remove that, or move it
to ~/.config/fish/completions/jj.fish which overrides the default completions.
Ref: https://github.com/fish-shell/fish-shell/pull/11046
The current behaviour means (transitively) dependent crates' debug logs end up
in our logs when `--debug` is active.
The biggest offender here is `globset`, imported from the `ignore
crate`. These logs are extremely noisy and mostly irrelevant from our usecase.
This commit changes this behaviour to whitelist `jj` related debug logs,
while allowing more debugging to come from env vars
If a signing key is not configured, the user's email will be
used as the signing key. This aligns with `git`'s behavior
and allows the users to not specify the key in their configs
given that they have a key associated with their email.
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.
The FAQ entry explaining why `jj log` doesn't show all commits
explained that the behavior is configurable but it didn't explain what
the rationale for not showing all commits is. Users coming from Git
are used to seeing all commits and probably read this FAQ entry to
find an answer. We don't want them to just update their config without
understanding why we have the default we have.
Suppose revsets and filesets are primarily used in command shell, it would be
annoying if quoting is required in addition to the shell quoting. We might also
want to relax the revset parser to allow bare * in glob string.
Closes#2101
- Swapped `file:"path"` and `cwd-file:"path"` for consistency with the first line
- Created a labeled section for quoting rules
- Elaborated on the quoting rules in the beginning of file pattern section.
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.
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 was requested on Discord once.
The result is almost a tutorial; we could consider actually moving it into the
tutorial and providing a link in the FAQ. That could be done separately.
The `jj` commands outputs are faked in a few, hopefully inconspicuous, ways.
Hopefully, this is not distracting.
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`.
