As a follow-up to #8115, this moves all references in the codebase to use the new website.
I didn't update the older CHANGELOG entries because I figured they're intended
to be immutable.
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
Up until now, trying to get a config value that was an array or a table would fail with an error indicating that only values that can be converted to a string can be displayed. This change fixes that issue by converting arrays and tables into TOML format.
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
Tombi is an LSP that complains about the "$schema" key, because it
itself is not actually part of our schema. Taplo is another LSP that
can read this comment directive. Using a comment seems generally more
appropriate. Syntax highlighting makes comments usually less visible,
indicating that the directive is not actually part of the configuration
data.
This is a simple computation over the JSON structure of the schema,
so it doesn’t need pulling in another programming language and a
dependency on an external C program to interpret it.
Extracts the `"default"` values from the schema and creates a synthetic
TOML file holding all the defaults according to the schema. This is done
through some `jq` magic and is not perfect but rather a best effort.
If `jq` is not available, the test is skipped; in CI `jq` is required.
The test then run `jj config get` in the test env for each key in that
defaults file and compares the resulting value with the schema default.
For a few keys, there are actually no defaults known to `jj config get`,
because they are hard-coded or dynamic. These exceptions are intercepted
and explained in the test.
Using the `cfg_attr` attribute means the test is still compiled on non-macOS
architectures and checked but is ignored and not run, instead of running and passing.
Instead of saying to move configuration files from
`~/Library/Application Support` to `~/.config`, jj now tells you to move
configuration files from `~/Library/Application Support/jj` to
`~/.config/jj`.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
It seems like a small usability improvement if users don't need to
enter the "$schema" link manually when they create a new config file.
This doesn't help existing users.
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).
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.
This allows the user to select a particular file when using multiple
configs. In the event that a prompt cannot be displayed, the first
file will be automatically selected.
I'm going to add "[EOF]" marker to test that command output is terminated by
newline char. This patch ensures that callers who expect a raw output string
would never be affected by any normalization passes.
Some common normalization functions are extracted as CommandOutputString
methods.
Closes#5217
Motivating use case:
[[--scope]]
--when.command = ["log"]
[--scope.ui]
pager = "less"
This adds a new (optional) field to `--when` config conditions, to
inspect the current command.
`--when.commands` is a list of space-separated values that matches a
space-separated command. To be specific:
--when.command = ["file"] # matches `jj file show`, `jj file list`, etc
--when.command = ["file show"] # matches `jj file show`, but *NOT* `jj file list`
--when.command = ["file", "log"] # matches `jj file` *OR* `jj log` (or subcommand of either)
When both `--when.commands` and `--when.repositories` are set, the
intersection is used.
This is a middle ground. An inline table can still be overwritten or deleted
because it's syntactically a value. It would be annoying if "jj config set
colors.<name> '{ .. }'" couldn't be executed more than once because the existing
item was a table.
#5255
This backs out commit 0de36918e4. Documentation,
tests, and comments are updated accordingly. I also add ConfigTableLike type
alias as we decided to abstract table-like items away.
Closes#5255
