--clean deletes each workspace's working_copy/ and state/ directories
after acquiring the lock, so every commit starts from a freshly
checked-out tree. Build artifacts from previous runs are not reused.
Previously, we created a new unique working copy for each invocation
named after the commit ID. This works but can be very slow to rebuild
the working copy and any ignored build artifacts between each
invocation.
Workspaces used for `jj run` are now named `1`, `2`, ..., `N`, where `N`
comes from either `--jobs N`, the config value `run.jobs`, or defaults
to 1.
Remove the single global lock that prevented multiple `jj run` instances
from executing concurrently. Multiple processes wait for each workspace
individually.
Workspaces persist between command invocations so build artifacts are
reused. The `tree_state` file in each is used to check out the next
revision while leaving ignored files in place.
The previous "fresh workspace" behavior will be restored in a future
commit that adds a `--clean` flag.
Also drops the documentation example with default config list template, as
generally it's not useful to list an example TOML block with the default values.
Fixes#9428
This allows jj to support custom options provided by the git server.
For example, chromium sometimes requires `git push -o nokeycheck`
if you intentionally uploaded a private key.
While it's a bit odd that the glob pattern and exact remote symbol arguments are
overloaded, the symbol syntax is undeniably convenient.
`RemoteBookmarkNamePattern` and `Display for StringPattern` have been removed as
they are no longer used.
Closes#9226Closes#9426
You could just `cat .jj/repo/store/type` instead, but that feels like
too much of an implementation detail.
This can be used in scripting to perform different actions based on the
backend being used. For instance, an `aliases.upload` script may check
that the backend is "git" before running `jj git push`. If more upstream
backends are added in the future, such an alias could be updated to
handle those as well. (Google has its own commit backend, so Google
users may already find benefit in this command.)
Even though log -p can already be used to view a list of commits and their changes,
`jj show` offers a nicer default for this purpose specifically.
This change also nicely mimics `git show` and how it handles multiple commits.
This helps test experimental remote tags and migrate away from implicit tag
fetching. Suppose the default fetch-tags is changed to '*', users who have tons
of uninteresting remote tags will have to override the fetch-tags pattern.
Closes#7819
Allows passing multiple `hashtag`s adds `message`, `edit` and `merged`
options. We are still missing `base` (should that allow passing revset
descriptions or only git commit hashes? Would have to convert),
`push-justification` (documentation says it's Google internal) and
`create-cod-token` (undocumented, Google internal option. Listed in
gerrit source code).
The `--pattern` flag now supports `kind:pattern` syntax.
The `kind` part is optional, and the pattern is treated
as regex when omitted.
Related to #7940
It was unclear (from the short help) which revision would get the given
description. Also I find it easier to think in terms of what was
selected rather than "first commit" and "second commit".
Updated the CLI to support line range based file fixing.
* We added `line_range_arg` and `run_tool_if_zero_line_ranges` to `ToolConfig` so users can configure how changed line ranges are passed to tools and explicitly specify whether a tool should run when there are zero modified lines.
* We introduced the `--all-lines` argument to allow users to fall back to the previous behavior of formatting the entire file when `line_range_arg` is specified.
* We use a new `compute_regions_to_format` function to calculate the changed line ranges dynamically before applying each individual formatter tool in the sequence.
* Because a formatter tool might add or remove lines, shifting the line numbers for subsequent tools, this determines the exact target ranges by diffing the static base file content against the intermediate output of the previous tool.
* To validate this logic, we extended the `fake-formatter` test fixture with a `--line-ranges` argument to restrict execution to specific lines. We also introduced a `--split-even-length-lines` flag to mimic realistic formatters that expand line counts, proving our dynamic range recalculation properly shifts lines in complete end-to-end tests.
This patch adds a global `--no-integrate-operation` flag that prevents
integration/publishing of most operations, including the ones created by
`snapshot_working_copy()` and `finish_transaction()`. The operations
are still created as usual.
We provide `jj op integrate` to manually reintegrate operations created by
commands with this flag enabled.
Closes#2562
Co-authored-by: Martin von Zweigbergk <martinvonz@google.com>
Add documentation showing how `jj tag list -r` with revset expressions
can be used to filter tags, replacing the need for dedicated flags like
`git tag --contains` or `git tag --merged`. For example,
`jj tag list -r 'REV::'` lists tags whose targets descend from REV.
Tag operations were missing entirely from the Git command comparison
table, so this also adds entries for listing, creating, and deleting
tags alongside the filtering equivalents. The `jj tag list` help text
and the revsets doc both gain examples demonstrating these patterns.
This change introduces elision of "non-salient" revisions in `jj op show`,
`jj op diff`, and `jj op log -p`. This helps keep the output focused on
meaningful changes (like mutable commits) while summarizing less relevant
changes (like large sets of immutable revisions being added or removed).
A new configuration setting `revsets.op-diff-changes-in` defines which revisions
should be shown. It defaults to `mutable() | immutable_heads()`.
A new `--show-changes-in` flag is added to these commands to allow overriding
the default elision behavior for a single invocation (e.g., `--show-changes-in=all()`).
Summary of changes:
- Added `revsets.op-diff-changes-in` config with default `mutable() | immutable_heads()`.
- Implemented filtering and elision logic in `compute_operation_commits_diff`.
- Updated `op show`, `op diff`, and `op log -p` to honor the new elision behavior.
- Added elision summaries to the output (e.g., "Elided X newly removed revisions").
- Updated documentation in `docs/config.md`.
- Added comprehensive integration tests in `cli/tests/test_operations.rs`.
Having a mix of flags in the singular and plural form is confusing.
In some cases, e.g. `gerrit upload --reviewer`, only a single value is
accepted per flag invocation. To supply multiple values, the flag has
to be repeated. In such cases, it makes more sense to use the singular
form. In other cases, e.g. `jj log --revision(s)`, a single flag
invocation may be provided with multiple revisions (in the form of a
revset). There, using the plural form would also make sense. But, for
consistency, the singular is used in all cases.
This reverts commit 4dc6323bfd.
There's talk about maybe making the command accept paths, so let's
revert this at least for now so it's not part of the next
release. That way we have more time to think about it.
Document the default behavior, when `--remote` is not specified, in the
main command documentation, alongside the documentation for the case
where `--tag` and `--branch` are not specified. Don't put it in the
documentation for the `--remote` flag, since it's not documentation
about the behavior of that flag.
A common recommendation for new users is for them to add a `jj tug`
alias. This change makes that alias unnecessary by adding a native
version.
The command has customization points `revsets.advance-default-to`
and `revset-aliases.closest_bookmarks(to)` to adapt to different workflows.
The default target is `@` for parity with other bookmark commands.
Possible useful revsets to use can be found in
https://github.com/jj-vcs/jj/discussions/5568#discussioncomment-12674748.
Co-authored-by: Scott Taylor <scott11x8@gmail.com>
This essentially does the same thing as `jj debug snapshot`, but is
actually officially documented and thus "supported". We've added it to
the `util` subcommand because that seems more intuitive for the end
user, despite other `util` commands not usually needing the repo at all.
It's currently not a syntax error to not pass any revision
arguments. It results in "No revisions to revert." instead. This patch
makes it an error, which means clap will help us give the user a
better error message.
I don't see a reason not to allow revisions as positional arguments
for `jj revert`. I don't think we'll ever want to pass path arguments
to the command.
Unlike the other commands that accept revisions as positional or named
arguments, I didn't make the named one hidden here since it's already
been visible for a long time.
This behavior is similar to "jj git push". If we add "jj git push --tag" option,
it would disable the default revset.
No changelog entry is added because "jj git fetch --tag" isn't released yet.
It's also experimental.
- Added example command showing --author flag usage to metaedit.rs
The docs show examples for other similar commands, but not for the
author command. Since the format is not obvious an example is helpful.
When `git.colocate` config is true (the default), the `--git-repo` flag
for `jj git init` was silently ignored. This happened because the
colocate logic was checked before the --git-repo logic:
let colocate = if command.settings().get_bool("git.colocate")? {
!args.no_colocate // true unless --no-colocate passed
} else {
args.colocate
};
Then in `do_init()`:
let init_mode = if colocate {
// takes this branch, ignoring --git-repo!
} else if let Some(path_str) = git_repo {
// --git-repo handling never reached
}
This meant `--git-repo` was simply ignored unless `--no-colocate` was also
passed.
This is a regression from when colocation became the default. Before
that change, `--git-repo` worked without any additional flags because
`colocate` defaulted to false. The fix preserves that original behavior
by checking for `--git-repo` first and setting `colocate = false` when
it's provided, allowing the --git-repo code path to be reached.
This change adds the ability to provide a description for the commit
when a workspace is added.
Example:
```
$ jj workspace add -m "wip bugfix" --name bugfix ../bugfix
Created workspace in "../bugfix"
Working copy (@) now at: xmskztnv 564c419d (empty) wip bugfix
Parent commit (@-) : zzzzzzzz 00000000 (empty) (no description set)
```
Currently, when a workspace is added, the new (empty) commit that is
created has no description set.
This change to `workspace add` mirrors the option to the `new` command,
which can take zero or more `-m/--message` flags for setting the
description for a new commit. The same logic for creating the new commit
for a workspace applies in terms of parent revisions, so this change
brings `new` and `workspace add` closer together in terms of CLI
affordances.
Similary to `new`, this change permits multiple message flags to be
supplied on the CLI. It also retains the behavior of not otherwise
creating a description of just trailers if no message flag were supplied
but trailers were set.
This allows `jj workspace root` command to take an optional workspace
arg to print the root directory of that workspace, while defaulting to
the current workspace.
We allow this by creating a new `workspace_store` which has a separate
entry for each workspace containing its name and root directory. This
store is created during initiation of the repo and is maintained
whenever `add`, `forget` & `rename` workspace subcommands are executed.
CAUTION: Moving a workspace path will not sync the path stored in the
workspace store.
CAUTION: Specifying `jj workspace root` with a workspace created before
this will result in an error.
