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.
* `Some(x).unwrap()` is not necessary.
* Add a new test to ensure that we handle the fix child process IO
without deadlock. The new test introduces byte mode to fake-formatter
which pipe the stdin contents to stdout byte by byte in a streaming
fashion. The test contents are 512KB, which is larger than page size,
can trigger the blocking read behavior, and doesn't make the test the
slowest.
Add an assertion that verifies the operation description actually
contains "import git head". This prevents the test from being
nullified if the operation description changes in the future.
Concurrent jj processes in colocated Git repos could create divergent
operations when importing/exporting Git HEAD. This change prevents the
race where two processes both load the repo at operation X, then create
divergent operations Y and Z with the same parent.
Fix by introducing a dedicated lock (.jj/repo/git_import_export.lock)
that serialises Git HEAD and refs import/export. The lock is acquired
in maybe_snapshot_impl() and finish_transaction(). After acquiring the
lock, we reload the repo at the current head to avoid creating operations
based on stale state.
Add a probabilistic test that spawns two jj processes in parallel:
one running `jj debug snapshot` (imports Git HEAD) and another
running `jj next/prev` (exports Git HEAD). The test creates large
commits to increase the race window and should fail when the race
condition exists. The race condition is fixed in the next commit.
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.
Deprecation warnings will be emitted for default "substring:" patterns. This
change will suppress them. Since "glob:" will be the new default, I made these
tests use "glob:" when both "exact:" and "glob:" work.
Tests for the revset filter functions aren't updated.
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.
The new parse_program() will allow us to parse top-level string patterns with no
parentheses. This patch also replaces a few callers of the old parse_program().
When we drop support for the all: modifier syntax, parse_program_with_modifier()
will be replaced entirely.
This paves the way to deprecate the `--allow-new` flag on `jj git push`
without adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks tracks all bookmarks at creation time, not when
they're about to be pushed. Where appropriate, I tracked bookmarks
manually instead of via the auto-track config.
Since this is a test for template output of various bookmark states, it's better
to not rely on implicit configuration. Local bookmark "new-bookmark" wasn't
tracked before.
This paves the way to deprecate `git.auto-local-bookmark` without
adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks also tracks bookmarks that were created locally.
I think it just shows up in output snapshots as absent-tracked
bookmarks, without affecting what the test is about.
I thought the lack of newline would be intentional when I added explicit ++ "\n"
by 4495574171 "templater: do not implicitly add final newline character to
commit.description", but that seems wrong. The compact_full_description template
would be largely copied from the compact template, and the author wouldn't
notice that .first_line() strips newline?
Suppose this template is closer to comfortable/detailed templates, a blank line
should also be inserted to the root commit.
Fixes#8073
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/*`).
The character used for splitting the argument from its description /
help text was incorrect. In the template syntax used to obtain those
information, a tab ('\t') was used, while the parsing split the line
base on the pattern ": ".
The result was that the suggested argument for completion was
systematically incorrect, as the help text is systematically added, with
a default to "(no description set)".
The test was also incorrect, the expected pattern, for each line, was
'<value>\t<description>' since <value> was actually
`<value>\t<description>` the test was badly configured to expect
`<value>\t<description>\t'.
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
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
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.
