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
I'm going to fix parsing of CLI string patterns to use revset parser, and it
would be annoying if inner quotes were required in addition to shell quotes:
$ jj bookmark list 'glob:"push-*"'
There's also a plan to enable glob matching globally. This will mean that we'll
have to use either `subject(*foo*)` or `subject(substring:foo)` for substring
search.
https://github.com/jj-vcs/jj/issues/6971#issuecomment-3067038313
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.
"watch" is the more common term to refer to tasks that run whenever a
relevant file changes. A prominent example is watchexec, a tool built
for this purpose.
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
This adds support for tracking ignored and oversized files with `jj file track`.
Previously, `jj file track` would silently fail to track files that were ignored by
`.gitignore` or larger than `snapshot.max-new-file-size`. This commit introduces an
`--include-ignored` flag that allows users to explicitly track these files.
## Implementation
Added a `force_tracking_matcher` field to `SnapshotOptions` that overrides ignore rules
and size limits. When `--include-ignored` is specified, the file pattern matcher is
passed as `force_tracking_matcher`, allowing three checks in `FileSnapshotter` to bypass
their usual restrictions for directory ignores, file ignores, and file size limits.
## Tests
- `test_track_ignored_with_flag`: Verifies `.gitignore`d files can be tracked
- `test_track_large_file_with_flag`: Verifies oversized files can be tracked
- `test_track_ignored_directory`: Verifies ignored directories can be tracked recursively
# Checklist
If applicable:
- [ ] I have updated `CHANGELOG.md`
- [x] I have updated the documentation (`README.md`, `docs/`, `demos/`)
- [ ] I have updated the config schema (`cli/src/config-schema.json`)
- [x] I have added/updated tests to cover my changes
Any keyword arguments given to the `coalesce()` and `concat()` functions
were being silently ignored because `FunctionCallNode.args` was being
accessed directly without checking `keyword_args` at all.
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.
This will be used as a default matcher for patterns including glob characters. I
don't think prefix matching on globs would be particularly useful, but the
default behavior should be compatible with PrefixMatcher.
Regarding the implementation, a glob regex is first translated to a prefix
pattern by replacing $ with (/|$). We can instead use low-level regex_automata
API to compute prefix matching, but that would be more involved.
GlobMatcher::visit() is slightly optimized as we know descendant paths always
match.
We should not display any warning if `explicit_paths` is empty.
Previously, we would by-pass this check if `trees` was empty (which was
incorrect behaviour).
Fixes#7024.
On Windows, where the native path separator is `\`, either `/` or `\`
can be used (at least in PowerShell which's supported by clap-complete).
To ensure that the input string indeed prefixes the candidate paths,
we now normalize both to use forward slashes. The remainder which is
spliced onto the input string will thus use forward slashes on all
platforms. That way, the completion is now also usable in git-bash.exe
(Git for Windows with `COMPLETE=bash`). When using dynamic completion
with PowerShell, the completion results are still valid, as PowerShell
can tolerate forward slashes.
Fixes#6861.
In the original `dir_prefix_from` function, `current` might not be a
prefix of the (normal) completion candidate `path` if `current` itself
is non-normal. In case `current` is longer than the candidate `path`,
the code previously panicked. The tests have been extended to trigger
this panic.
This commit rewrites how the file-path completion is determined from
a potentially non-normal `current_prefix`. The panic is avoided by
using `strip_prefix()` instead of direct slicing. The basic idea is to
normalize the `current_prefix` first to obtain an actual prefix of the
(normal) `path`. The remainder can then be spliced onto the original
`current_prefix` to form a non-normalized completion path that is
prefixed by `current_prefix`, allowing the shell to accept it.
This requires a different API for the helper than what `dir_prefix_from`
provided. The latter assumed that when `None` was returned, `path` could
be completed as-is; a `Some` value indicated a partial completion of
`path` to the next directory. This is no longer sufficient as we need to
potentially return a different, non-normal path in either case.
Since we want to ignore the `mode` for directory completions, the
helper must also return the type of completion (partial/directory
or full/file). To avoid propagating this information, I instead
pass the `mode` into the helper and have it return finished
`CompletionCandidate`s. This arguably yields cleaner code on the caller
side, too.
