The default patterns are still saved to and loaded from .git/config. Maybe we
can add default fetch patterns to jj's configuration, but I'm not sure whether
we should deprecate .git/config fallback.
If a submodule was created in a commit C on a remote repo, switching from any
commit after C to any commit before C (eg. `jj new C-`) will result in jj
starting to track the files introduced in the submodule.
This issue has popped up very frequently for chromium developers, who
get issues when attempting to check out an older version of chromium.
Fixes#4349
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.
Since the specified patterns are no longer guaranteed to match at least one
remote branch, the default (remote) branch is taken into account if exact
patterns match nothing. I think this is better because `-b glob:*` is now
identical to the default.
"jj bookmark move" no longer shows a warning for named bookmarks not pointing to
the --from revisions. I think that's okay. `move --from=REV 'PATTERN ~ main'` is
a valid use case, and "main" shouldn't be warned.
This prepares for migration to parse_union_name_patterns(). find_bookmarks*()
will be inlined, and new helper function for unmatched warnings will be added.
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.
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.
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.
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/*`).
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.
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
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.
As we have discussed many times on Discord and GitHub, `--destination`
is not a great name because `--insert-before` and `--insert-after` are
also destinations. The most popular alternative seems to be
`--onto`. We already use that term in descriptions in several places,
such as in the help text for `rebase -d` where we say "The revision(s)
to rebase onto". This patch therefore renames the `--destination` flag
to `--onto`.
The short name naturally becomes `-o`. That is perhaps a little
unfortunate because it's a common short name for `--output <file>`
arguments, but we don't use that anywhere so it seems fine.
Perhaps we should also rename `--source` (used by `rebase` and `fix`)
to something else. Perhaps the most obvious name is `--descendants`,
but the short form would be `-d`, which is of course already taken by
`--destination` in the case of `rebase`. Either way, I'm leaving that
rename for later. It would be good to do it before next release if we
are going to do it, though.
Closes#7941
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
