In order to write config settings of tools for jj fix, you needed
information that were split in the `jj fix --help` text and
`jj help -k config` (or the respective web-pages).
Move every bit of information that is important to know to write
`jj fix` configurations in the config page. This avoid to have to
maintain the information up-to-date in two places.
Organize the help text of `jj fix` with several chapters.
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.
This configuration allows users to express a set of bookmarks that
should be automatically tracked when first encountered. This includes
on clone, fetch, create and set.
Until now, the configuration values `git.push-new-bookmarks` and
`git.auto-local-bookmark` fulfilled parts of those use cases. However,
both options represent an "all or nothing" approach. By turning them on,
users risk tracking and pushing more bookmarks than desired.
By using a bookmark pattern, users can express that they want to
auto-track bookmarks that belong to them (e.g. `glob:my-name/*`).
Add documentation for the snapshot.auto-update-stale configuration
option that was added in commit 49890fa2d but not included in the
configuration documentation.
This option allows automatic updating of stale working copies, which
is particularly useful for users with multiple workspaces.
Fixes#8033
When `$PAGER` is set in the environment, jj uses that instead of the
default (`:builtin` on Windows, `less -FRX` everywhere else). Commonly,
users will have `PAGER=less` in their environment for various reasons,
and this is respected by jj. This means that every jj command, even one
that only outputs one or two lines, will still invoke a full screen
pager. It also means that every jj command which uses escape sequences
for color, which is most of them, will be output through a pager that
doesn't handle that well, so users see output that looks like this,
which isn't very readable:
```
ESC[1mESC[38;5;2m@ESC[0m ESC[1mESC[38;5;13mspmESC[38;5;8mwzlkq...
```
To fix this issue that new users stumble upon, ignore `$PAGER` from the
environment, and always use our per-platform default. Users can set
`ui.pager` to select whichever pager they prefer.
This seems like the least bad option for resolving #3502. The cases I
considered were:
1. User doesn't have `PAGER` set. No change.
2. User has `PAGER=less` in their environment. We'll still run `less`,
just with `-FRX`, so this seems fine. This case is surprisingly common.
3. User has `PAGER` set because they prefer another pager. We'll ignore
that preference and run `less -FRX`.
4. User has `PAGER` set because `less` isn't available on their
platform. This is uncommon except for Windows, where we'll run
`:builtin` instead of `less -FRX` by default anyway.
This may cause some users who have intentionally set and configured
`PAGER` to be frustrated that we aren't respecting that value, but it's
generally not possible to respect that value in all cases _and_ have a
consistent and usable experience out of the box for the majority of
users.
#### Alternatives considered
1. Disable color and OSC8 hyperlinks if `PAGER` is set, since we can't
be sure the pager supports the color codes.
2. Don't paginate by default if `PAGER` is set. This seems
counterintuitive, but would at least resolve the problem. Users would
assume that the `jj` CLI doesn't support paginating, and either wrap it
in a pager themselves (this is a bad outcome) or find `ui.pager` and
change the setting.
3. Set `LESS` (iff it's not set already), then invoke `PAGER`. This
means that users setting things like `LESS=i` breaks our output as well,
and cases where `PAGER` isn't 'less' aren't fixed.
Fixes#3502
This enables configuration to be conditionally applied based on the
hostname set in `operation.hostname`. Users can now use
`--when.hostnames = ["host-a", "host-b"]` in their config files to apply
settings only on specific machines.
Fixes: #6441
Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
We currently say "you can disable colocation which does X". If found
it unclear whether "X" describes what colocation does or what
disabling it does. I think can simply describe what colocation does
here. The next paragraph explains how to disable it.
- 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>
This follows Git's merge driver interface which makes this information
available using the `%P` variable. It is useful for merge drivers to
adapt their behaviour based on the type of file supplied.
I have no idea if we can change the default, but maybe we can conditionally
disable the same-change rule to get rid of hacks in squash_commits(), etc.?
resolve_file_executable() doesn't respect the Store configuration. I'm not sure
if that's the right choice, but it seemed better to accept duplicated change
than falling back to executable=false.
#6369
Adds a new `--when.platforms` condition for including configuration.
This is useful when someone syncs their dotfiles across machines.
The values for `platforms` are defined by `std::env::consts::FAMILY` and
``std::env::consts::OS. Any Unix-family platform can be specified using
the value `"unix"`, or individual operation systems can be chosen with
`"linux"`, `"macos"`, or `"windows"`.
Example:
```toml
ui.pager = ["less", "-FRX"]
[[--scope]]
--when.platforms = ["windows"]
ui.pager = ["C:/Program Files/Git/usr/bin/less.exe", "-FRX"]
```
This option affects emptiness of commits, which means indexed changed files can
become stale on configuration change. This problem can also be said for changes
in the diff algorithms, so I don't think we need a logic to invalidate index on
config change.
I have this patch for months, and it seems working good at least for Rust
sources.
Closes#17
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
The pico text editor is effectively absent from the majority of Linux
distributions, having been replaced with nano by virtually all of them.
Some distros have symlinks for `pico` that point to `nano`, but not all
of them. Using nano as the fallback option has a much lower chance of
failure than pico.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
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 patch doesn't add builtin_evolog_redacted template because I'm not sure if
we want to collect evolution log for debugging purpose. The redacted template
can be added later if needed.
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
On Windows, spawning a child process finds the command relative to the
parent's working directory. If a command is specified as
`["path/inside/repo/tool.exe"]`, then tool won't be found if `jj fix` is
run from a subdirectory of the workspace.
There doesn't seem to be a good way to change this behavior, nor does it
seem easy to convert `program` into an absolute path because
`["tool.exe"]` could refer either to a file on the PATH or a file
committed at the root of the repository.
So, we add a new variable `$root` that can be used in this situation.
Workspace-relative tools on Windows should be defined using this
variable:
```toml
# Tools on the PATH
command = ["tool.exe"]
# Workspace-relative tools
command = ["$root/tool.exe"]
command = ["$root/nested/dir/tool.exe"]
```
On Unix, the command is found relative to the working directory of the
child process, so this isn't an issue.
Fixes#7144
Not setting `diff-args` is equivalent to `diff-args=["$left",
"$right"]`, which I also documented here.
I couldn't decide whether the new error should be part of
`DiffRenderError`, `DiffGenerateError`, or `MergeToolError`. Since the
treatment of diff formatters is already very different from other merge
tools, I just made it a CommandError for now.
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
