While divergence is talked about in the documentation, few places actually
mention how divergent changes are displayed. I've added such notes to the help
out put of `jj log`, the glossary, and added an example to the guide we have on
divergence.
Fixes#6365
Delete the dead reference to bwb's cultivate which no longer is actively worked on since
in the mean time ersc was founded. Also sort the links in the doc.
The primary benefit of this change is that it splits
"lines_added()" and "lines_removed()" into separate fields,
which will be useful for tools.
Many tools use "status()", "lines_added()", "lines_removed()",
"source()" and "target()" to show useful information about
every file modified in a commit.
The existing diff stats summary shows only the combined
number of lines modified, along with a "percentage" representation
of line additions vs. deletions. This is lossy and not
useful for tools, since it is impossible to arrive at
the exact number of lines added and deleted.
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.
Glob patterns will be enabled by default globally. Since this will be a big
breaking change in revsets, this patch adds a config knob to turn the new
default on/off.
These commands are easy ones. The other commands error out if one of the
patterns doesn't match anything. I'll make them warn only exact patterns instead
to keep the implementation simple. I'll also add warnings to these list
commands.
Changed to be consistent, at least in the same file, and avoid
using sometime repository/repositories and other times repo/repos.
"repo/repos" is currently the most use terminology.
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
After 42f645ed28
the tests have slowed down significantly on macOS. Apparently, `fsyncdata`
is quite slow there. However, setting up a RAM disk works around this
and makes tests fast again.
Thanks to @yuja for suggesting the RAM disk solution.
Thanks to @davidbarsky for the APFS lock article link
When looking for a revset for visible commits, it seems natural to
reach for `visible()`. It's less obvious to find
`visible_heads()`.
Similarly, we don't have a revset for `hidden()` commits, so I added
that too. I defined it as the obvious `~visible()`. That doesn't
include all hidden commits reachable from the operation log (or from
the index). Maybe we'll want a revset for that eventually. Hopefully
we can come up with a decent name for it then. It's probably better to
define that as all of the historical commits including the current
ones in that case, so `hidden()` would not be a good name.
Not quite sure why the previous version used a subshell expression when
the output could just as easily be piped to `Invoke-Expression`.
This is more akin to how `source` works in Fish as opposed to the Bash
builtin.
This also splits the instructions for dynamic completions into separate
lines. I think that helps better understand what's going on (PowerShell
lacks temporary environment variables) and avoid scrolling.
On Windows, PowerShell scripts are not allowed to be executed by default
due to the default execution policy `Restricted`. This includes the
`$PROFILE` script (even though PowerShell will still happily attempt to
source it if it exist, resulting in "running scripts is disabled on this
system" errors every time it starts... go figure...).
To avoid this, you generally need to set the execution policy to at
least `RemoteSigned` (which will only block scripts downloaded from the
internet which are not signed; this is the default on Windows Server).
This can be done by running
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
as an administrator, though there tends to be [discussions][1] about the
security tradeoffs of scope and granularity, so I think it is best to
link to the MS documentation on execution policies to allow users to
draw their own conclusions.
This issue does not affect PowerShell users on Linux or macOS.
[1]: https://superuser.com/questions/106360/how-to-enable-execution-of-powershell-scripts
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
Since file names don't usually include glob meta characters, it's probably okay
to enable globs by default. There's also a plan to change the default of string
patterns to globs.
The short forms "cwd:"/"root:" are still aliased to literal patterns. I don't
have a strong reason to rename these.
Closes#6971
"prefix-glob:" will be the default. I don't think these prefix glob patterns
are useful, but they are added for completeness.
It's odd that literal patterns do prefix matching by default whereas globs match
exactly. We can instead rename the existing "glob:" to "file-glob:" and add
prefix "glob:", but I'm not sure which is better.
