mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-01-15 16:53:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
jj/cli/tests/test_operations.rs

2267 lines
90 KiB
Rust
Raw Normal View History

copyright: change from "Google LLC" to "The Jujutsu Authors" Let's acknowledge everyone's contributions by replacing "Google LLC" in the copyright header by "The Jujutsu Authors". If I understand correctly, it won't have any legal effect, but maybe it still helps reduce concerns from contributors (though I haven't heard any concerns). Google employees can read about Google's policy at go/releasing/contributions#copyright.
2022-11-26 23:57:50 +00:00
// Copyright 2022 The Jujutsu Authors
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
use std::path::Path;
tests: avoid hardcoding commit/operation ids when possible Hardcoded ids cannot be updated with `insta`.
2023-05-21 07:17:39 +00:00
use itertools::Itertools;
Have `jj op log` obey `ui.relative-timestamps` option
2023-01-07 03:43:46 +00:00
use regex::Regex;
formatting only: switch to Item level import ganularity
2024-08-22 18:18:15 +00:00
use crate::common::get_stdout_string;
use crate::common::strip_last_line;
use crate::common::TestEnvironment;
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
#[test]
fn test_op_log() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
let repo_path = test_env.env_root().join("repo");
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "description 0"]);
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
Make `ui.relative-timestamps` default to true This seems like a better default for `jj op log`, which is now the only thing this option affects.
2023-02-16 03:19:41 +00:00
let stdout = test_env.jj_cmd_success(
&repo_path,
Rename `ui.relative-timestamps` to `ui.oplog-relative-timestamps`
2023-02-16 03:26:31 +00:00
&[
"op",
"log",
"--config-toml",
templater: migrate op log to template language The outermost "op-log" label isn't moved to the default template. I think it belongs to the command's formatter rather than the template. Old bikeshedding items: - "current_head", "is_head", or "is_head_op" => renamed to "current_operation" - "templates.op-log" vs "templates.op_log" (the whole template is labeled as "op-log") => renamed to "op_log" - "template-aliases.'format_operation_duration(time_range)'" => renamed to 'format_time_range(time_range)'
2023-02-19 08:05:50 +00:00
"template-aliases.'format_time_range(x)' = 'x'",
Rename `ui.relative-timestamps` to `ui.oplog-relative-timestamps`
2023-02-16 03:26:31 +00:00
],
Make `ui.relative-timestamps` default to true This seems like a better default for `jj op log`, which is now the only thing this option affects.
2023-02-16 03:19:41 +00:00
);
tests: use snapshot testing for operation log The operation IDs are now predictable in tests.
2022-11-22 17:11:40 +00:00
insta::assert_snapshot!(&stdout, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ c1851f1c3d90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
│ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe -m 'description 0'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
│ add workspace 'default'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
│ initialize repo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
"###);
tests: avoid hardcoding commit/operation ids when possible Hardcoded ids cannot be updated with `insta`.
2023-05-21 07:17:39 +00:00
let op_log_lines = stdout.lines().collect_vec();
let add_workspace_id = op_log_lines[3].split(' ').nth(2).unwrap();
let initialize_repo_id = op_log_lines[5].split(' ').nth(2).unwrap();
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
// Can load the repo at a specific operation ID
cli: add one more operation to test_op_log() Also made op id variables less dynamic as operation ids are now stable in tests.
2022-12-12 11:43:28 +00:00
insta::assert_snapshot!(get_log_output(&test_env, &repo_path, initialize_repo_id), @r###"
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ 0000000000000000000000000000000000000000
tests: re-run with `insta` crate version b9d99e87065b
2022-04-28 23:32:18 +00:00
"###);
cli: add one more operation to test_op_log() Also made op id variables less dynamic as operation ids are now stable in tests.
2022-12-12 11:43:28 +00:00
insta::assert_snapshot!(get_log_output(&test_env, &repo_path, add_workspace_id), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ 230dd059e1b059aefc0da06a2e5a7dbf22362f22
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ 0000000000000000000000000000000000000000
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
"###);
// "@" resolves to the head operation
insta::assert_snapshot!(get_log_output(&test_env, &repo_path, "@"), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 19611c995a342c01f525583e5fcafdd211f6d009
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ 0000000000000000000000000000000000000000
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
"###);
cli: add hard-coded support for specifying previous operation It's useful for testing to be able to specify some operation that's not the latest one. I didn't update the changelog because this feature is mostly for testing.
2022-04-20 05:51:52 +00:00
// "@-" resolves to the parent of the head operation
insta::assert_snapshot!(get_log_output(&test_env, &repo_path, "@-"), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ 230dd059e1b059aefc0da06a2e5a7dbf22362f22
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ 0000000000000000000000000000000000000000
cli: add hard-coded support for specifying previous operation It's useful for testing to be able to specify some operation that's not the latest one. I didn't update the changelog because this feature is mostly for testing.
2022-04-20 05:51:52 +00:00
"###);
cli: resolve operation symbol first and apply '-' postfix repeatedly Just like revsets.
2022-12-12 11:18:06 +00:00
insta::assert_snapshot!(
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
test_env.jj_cmd_failure(&repo_path, &["log", "--at-op", "@----"]), @r###"
Error: The "@----" expression resolved to no operations
cli: resolve operation symbol first and apply '-' postfix repeatedly Just like revsets.
2022-12-12 11:18:06 +00:00
"###);
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
// We get a reasonable message if an invalid operation ID is specified
tests: re-run with `insta` crate version b9d99e87065b
2022-04-28 23:32:18 +00:00
insta::assert_snapshot!(test_env.jj_cmd_failure(&repo_path, &["log", "--at-op", "foo"]), @r###"
Error: Operation ID "foo" is not a valid hexadecimal prefix
"###);
cli: add hard-coded support for specifying previous operation It's useful for testing to be able to specify some operation that's not the latest one. I didn't update the changelog because this feature is mostly for testing.
2022-04-20 05:51:52 +00:00
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log", "--op-diff"]);
insta::assert_snapshot!(&stdout, @r#"
@ c1851f1c3d90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe -m 'description 0'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 19611c99 (empty) description 0
│ - qpvuntsm hidden 230dd059 (empty) (no description set)
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 230dd059 (empty) (no description set)
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
│
│ Changed commits:
│ ○ Change zzzzzzzzzzzz
│ + zzzzzzzz 00000000 (empty) (no description set)
○ 000000000000 root()
"#);
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "description 1"]);
test_env.jj_cmd_ok(
cli: add hard-coded support for specifying previous operation It's useful for testing to be able to specify some operation that's not the latest one. I didn't update the changelog because this feature is mostly for testing.
2022-04-20 05:51:52 +00:00
&repo_path,
&[
"describe",
"-m",
"description 2",
"--at-op",
cli: add one more operation to test_op_log() Also made op id variables less dynamic as operation ids are now stable in tests.
2022-12-12 11:43:28 +00:00
add_workspace_id,
cli: add hard-coded support for specifying previous operation It's useful for testing to be able to specify some operation that's not the latest one. I didn't update the changelog because this feature is mostly for testing.
2022-04-20 05:51:52 +00:00
],
);
tests: re-run with `insta` crate version b9d99e87065b
2022-04-28 23:32:18 +00:00
insta::assert_snapshot!(test_env.jj_cmd_failure(&repo_path, &["log", "--at-op", "@-"]), @r###"
op_walk: add error types for fake "opset" expression This removes CommandError dependency from these resolution functions. We might want to refactor the error types again if we introduce a real "opset" evaluator. The error message for unresolved op heads now includes "@" instead of the whole expression.
2023-12-30 13:56:50 +00:00
Error: The "@" expression resolved to more than one operation
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
Hint: Try specifying one of the operations by ID: c05f56726c27, f9fdb4e100bd
tests: re-run with `insta` crate version b9d99e87065b
2022-04-28 23:32:18 +00:00
"###);
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
}
Make node symbols templatable in the graphs. Adds config options * templates.log_graph_node * templates.log_graph_node_elided * templates.op_log_graph_node
2024-03-11 22:16:24 +00:00
#[test]
fn test_op_log_with_custom_symbols() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Make node symbols templatable in the graphs. Adds config options * templates.log_graph_node * templates.log_graph_node_elided * templates.op_log_graph_node
2024-03-11 22:16:24 +00:00
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "description 0"]);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"log",
"--config-toml",
concat!(
"template-aliases.'format_time_range(x)' = 'x'\n",
"templates.op_log_node = 'if(current_operation, \"$\", if(root, \"┴\", \"┝\"))'",
),
],
);
insta::assert_snapshot!(&stdout, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
$ c1851f1c3d90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
Make node symbols templatable in the graphs. Adds config options * templates.log_graph_node * templates.log_graph_node_elided * templates.op_log_graph_node
2024-03-11 22:16:24 +00:00
│ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe -m 'description 0'
┝ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
┝ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
┴ 000000000000 root()
"###);
}
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
#[test]
fn test_op_log_with_no_template() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
let repo_path = test_env.env_root().join("repo");
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["op", "log", "-T"]);
undo: Report what operation has been undone in `jj op undo`
2024-09-12 14:20:57 +00:00
insta::assert_snapshot!(stderr, @r#"
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
error: a value is required for '--template <TEMPLATE>' but none was supplied
For more information, try '--help'.
Hint: The following template aliases are defined:
- builtin_log_comfortable
- builtin_log_compact
- builtin_log_detailed
Add template aliases with node symbol configs.
2024-04-13 19:12:16 +00:00
- builtin_log_node
- builtin_log_node_ascii
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
- builtin_log_oneline
- builtin_op_log_comfortable
- builtin_op_log_compact
Add template aliases with node symbol configs.
2024-04-13 19:12:16 +00:00
- builtin_op_log_node
- builtin_op_log_node_ascii
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
- commit_summary_separator
- description_placeholder
- email_placeholder
- name_placeholder
undo: Report what operation has been undone in `jj op undo`
2024-09-12 14:20:57 +00:00
"#);
cli: enrich the error about required template value with a hint Several `jj` commands accept `--template <TEMPLATE>` argument. When the argument is empty, `jj` will show the list of defined template aliases.
2024-03-03 06:04:59 +00:00
}
cli: add "--limit N" option to log-like commands Copied from Mercurial. This isn't a revset predicate since our revset is conceptually unordered.
2023-08-10 09:14:54 +00:00
#[test]
fn test_op_log_limit() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: add "--limit N" option to log-like commands Copied from Mercurial. This isn't a revset predicate since our revset is conceptually unordered.
2023-08-10 09:14:54 +00:00
let repo_path = test_env.env_root().join("repo");
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log", "-Tdescription", "--limit=1"]);
insta::assert_snapshot!(stdout, @r###"
@ add workspace 'default'
"###);
cli: add `jj op log --no-graph` Seems useful, and makes it consistent with the `jj log` and `jj obslog`.
2023-09-10 16:34:30 +00:00
}
#[test]
fn test_op_log_no_graph() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: add `jj op log --no-graph` Seems useful, and makes it consistent with the `jj log` and `jj obslog`.
2023-09-10 16:34:30 +00:00
let repo_path = test_env.env_root().join("repo");
let stdout =
test_env.jj_cmd_success(&repo_path, &["op", "log", "--no-graph", "--color=always"]);
insta::assert_snapshot!(stdout, @r###"
op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.
2024-02-18 22:57:09 +00:00
b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj op log --no-graph` Seems useful, and makes it consistent with the `jj log` and `jj obslog`.
2023-09-10 16:34:30 +00:00
add workspace 'default'
op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.
2024-02-18 22:57:09 +00:00
9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj op log --no-graph` Seems useful, and makes it consistent with the `jj log` and `jj obslog`.
2023-09-10 16:34:30 +00:00
initialize repo
cli: give root operation special treatment in template (like root commit)
2024-01-14 01:02:15 +00:00
000000000000 root()
cli: add `jj op log --no-graph` Seems useful, and makes it consistent with the `jj log` and `jj obslog`.
2023-09-10 16:34:30 +00:00
"###);
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log", "--op-diff", "--no-graph"]);
insta::assert_snapshot!(&stdout, @r#"
b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
add workspace 'default'
Changed commits:
Change qpvuntsmwlqt
+ qpvuntsm 230dd059 (empty) (no description set)
9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
initialize repo
Changed commits:
Change zzzzzzzzzzzz
+ zzzzzzzz 00000000 (empty) (no description set)
000000000000 root()
"#);
cli: add "--limit N" option to log-like commands Copied from Mercurial. This isn't a revset predicate since our revset is conceptually unordered.
2023-08-10 09:14:54 +00:00
}
Allow \0 escape for nulls This allows safely getting e.g. multiple descriptions, and knowing where the boundaries are
2023-09-13 17:50:12 +00:00
#[test]
fn test_op_log_no_graph_null_terminated() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Allow \0 escape for nulls This allows safely getting e.g. multiple descriptions, and knowing where the boundaries are
2023-09-13 17:50:12 +00:00
let repo_path = test_env.env_root().join("repo");
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "message1"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "message2"]);
Allow \0 escape for nulls This allows safely getting e.g. multiple descriptions, and knowing where the boundaries are
2023-09-13 17:50:12 +00:00
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"log",
"--no-graph",
"--template",
r#"id.short(4) ++ "\0""#,
],
);
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
insta::assert_debug_snapshot!(stdout, @r###""8a30\05cec\0b514\09a7d\00000\0""###);
Allow \0 escape for nulls This allows safely getting e.g. multiple descriptions, and knowing where the boundaries are
2023-09-13 17:50:12 +00:00
}
cli: add "op log -T" option and basic tests for template keywords
2023-02-19 09:15:54 +00:00
#[test]
fn test_op_log_template() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: add "op log -T" option and basic tests for template keywords
2023-02-19 09:15:54 +00:00
let repo_path = test_env.env_root().join("repo");
let render = |template| test_env.jj_cmd_success(&repo_path, &["op", "log", "-T", template]);
templater: require infix ++ operator to concatenate expressions This eliminates ambiguous parsing between "func()" and "expr ()". I chose "++" as template concatenation operator in case we want to add bit-wise negate operator. It's also easier to find/replace than "~".
2023-02-28 11:30:57 +00:00
insta::assert_snapshot!(render(r#"id ++ "\n""#), @r###"
op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.
2024-02-18 22:57:09 +00:00
@ b51416386f2685fd5493f2b20e8eec3c24a1776d9e1a7cb5ed7e30d2d9c88c0c1e1fe71b0b7358cba60de42533d1228ed9878f2f89817d892c803395ccf9fe92
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af88a2f7a1e348fb46ff58729e49632bc9c6a052aec8501563cb0d10f4a4e6010ffde529f84a2b9b5b3a4c211a889106a41f6c076dfdacc79f6af7
○ 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
cli: add "op log -T" option and basic tests for template keywords
2023-02-19 09:15:54 +00:00
"###);
insta::assert_snapshot!(
render(r#"separate(" ", id.short(5), current_operation, user,
templater: require infix ++ operator to concatenate expressions This eliminates ambiguous parsing between "func()" and "expr ()". I chose "++" as template concatenation operator in case we want to add bit-wise negate operator. It's also easier to find/replace than "~".
2023-02-28 11:30:57 +00:00
time.start(), time.end(), time.duration()) ++ "\n""#), @r###"
op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.
2024-02-18 22:57:09 +00:00
@ b5141 true test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 2001-02-03 04:05:07.000 +07:00 less than a microsecond
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d8 false test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 2001-02-03 04:05:07.000 +07:00 less than a microsecond
○ 00000 false @ 1970-01-01 00:00:00.000 +00:00 1970-01-01 00:00:00.000 +00:00 less than a microsecond
cli: add "op log -T" option and basic tests for template keywords
2023-02-19 09:15:54 +00:00
"###);
templater: make .short(negative_len) return 0-length string I think this is less surprising than falling back to the default length. i64-to-usize conversion can also overflow on 32 bit environment, but I'm not bothered to handle overflow scenario.
2023-08-25 10:04:54 +00:00
templater: turn some integer overflow into evaluation error FWIW, this kind of errors can be checked at parsing phase if we implement constant folding. I don't think that would matter in practice, though.
2024-02-27 11:37:00 +00:00
// Negative length shouldn't cause panic.
templater: make .short(negative_len) return 0-length string I think this is less surprising than falling back to the default length. i64-to-usize conversion can also overflow on 32 bit environment, but I'm not bothered to handle overflow scenario.
2023-08-25 10:04:54 +00:00
insta::assert_snapshot!(render(r#"id.short(-1) ++ "|""#), @r###"
templater: turn some integer overflow into evaluation error FWIW, this kind of errors can be checked at parsing phase if we implement constant folding. I don't think that would matter in practice, though.
2024-02-27 11:37:00 +00:00
@ <Error: out of range integral type conversion attempted>|
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ <Error: out of range integral type conversion attempted>|
○ <Error: out of range integral type conversion attempted>|
templater: make .short(negative_len) return 0-length string I think this is less surprising than falling back to the default length. i64-to-usize conversion can also overflow on 32 bit environment, but I'm not bothered to handle overflow scenario.
2023-08-25 10:04:54 +00:00
"###);
tests: use absolute timestamps in the operation log The current use of `timestamp.ago()` in the default template makes the tests depend on the current time, which they shouldn't.
2023-04-08 00:34:12 +00:00
// Test the default template, i.e. with relative start time and duration. We
// don't generally use that template because it depends on the current time,
// so we need to reset the time range format here.
test_env.add_config(
r#"
[template-aliases]
'format_time_range(time_range)' = 'time_range.start().ago() ++ ", lasted " ++ time_range.duration()'
"#,
);
let regex = Regex::new(r"\d\d years").unwrap();
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
insta::assert_snapshot!(regex.replace_all(&stdout, "NN years"), @r###"
op_store: add metadata flag for ops representing working-copy snapshot It should be useful at least in the presentation layer to know which operations correspond to working-copy snapshots. They might be rendered differently in the graph, for example. Or maybe an undo command wants to warn if you just undid a snapshot operation. This patch just introduces a field in the metadata to store the information.
2024-02-18 22:57:09 +00:00
@ b51416386f26 test-username@host.example.com NN years ago, lasted less than a microsecond
tests: use absolute timestamps in the operation log The current use of `timestamp.ago()` in the default template makes the tests depend on the current time, which they shouldn't.
2023-04-08 00:34:12 +00:00
│ add workspace 'default'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af test-username@host.example.com NN years ago, lasted less than a microsecond
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
│ initialize repo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
tests: use absolute timestamps in the operation log The current use of `timestamp.ago()` in the default template makes the tests depend on the current time, which they shouldn't.
2023-04-08 00:34:12 +00:00
"###);
cli: add "op log -T" option and basic tests for template keywords
2023-02-19 09:15:54 +00:00
}
templates: extract default template to an alias This way you can do `jj log -T 'default_log_template + "\n"'` to add a blank line between commits.
2023-04-13 17:30:48 +00:00
#[test]
fn test_op_log_builtin_templates() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
templates: extract default template to an alias This way you can do `jj log -T 'default_log_template + "\n"'` to add a blank line between commits.
2023-04-13 17:30:48 +00:00
let repo_path = test_env.env_root().join("repo");
templates: add missing "\n" to builtin "root" output
2024-03-13 13:36:03 +00:00
// Render without graph and append "[EOF]" marker to test line ending
let render = |template| {
test_env.jj_cmd_success(&repo_path, &["op", "log", "-T", template, "--no-graph"])
+ "[EOF]\n"
};
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "description 0"]);
templates: extract default template to an alias This way you can do `jj log -T 'default_log_template + "\n"'` to add a blank line between commits.
2023-04-13 17:30:48 +00:00
insta::assert_snapshot!(render(r#"builtin_op_log_compact"#), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
c1851f1c3d90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
templates: add missing "\n" to builtin "root" output
2024-03-13 13:36:03 +00:00
describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
args: jj describe -m 'description 0'
b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
add workspace 'default'
9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
initialize repo
000000000000 root()
[EOF]
templates: extract default template to an alias This way you can do `jj log -T 'default_log_template + "\n"'` to add a blank line between commits.
2023-04-13 17:30:48 +00:00
"###);
insta::assert_snapshot!(render(r#"builtin_op_log_comfortable"#), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
c1851f1c3d90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
templates: add missing "\n" to builtin "root" output
2024-03-13 13:36:03 +00:00
describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
args: jj describe -m 'description 0'
b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
add workspace 'default'
9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
initialize repo
000000000000 root()
[EOF]
templates: extract default template to an alias This way you can do `jj log -T 'default_log_template + "\n"'` to add a blank line between commits.
2023-04-13 17:30:48 +00:00
"###);
}
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
#[test]
fn test_op_log_word_wrap() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
let repo_path = test_env.env_root().join("repo");
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
std::fs::write(repo_path.join("file1"), "foo\n".repeat(100)).unwrap();
test_env.jj_cmd_ok(&repo_path, &["debug", "snapshot"]);
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
let render = |args: &[&str], columns: u32, word_wrap: bool| {
let mut args = args.to_vec();
if word_wrap {
args.push("--config-toml=ui.log-word-wrap=true");
}
let assert = test_env
.jj_cmd(&repo_path, &args)
.env("COLUMNS", columns.to_string())
.assert()
.success()
.stderr("");
get_stdout_string(&assert)
};
// ui.log-word-wrap option works
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
insta::assert_snapshot!(render(&["op", "log"], 40, false), @r#"
@ cf25045e0079 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ snapshot working copy
│ args: jj debug snapshot
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
│ add workspace 'default'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
│ initialize repo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
"#);
insta::assert_snapshot!(render(&["op", "log"], 40, true), @r#"
@ cf25045e0079
│ test-username@host.example.com
│ 2001-02-03 04:05:08.000 +07:00 -
│ 2001-02-03 04:05:08.000 +07:00
│ snapshot working copy
│ args: jj debug snapshot
○ b51416386f26
tests: use absolute timestamps in the operation log The current use of `timestamp.ago()` in the default template makes the tests depend on the current time, which they shouldn't.
2023-04-08 00:34:12 +00:00
│ test-username@host.example.com
│ 2001-02-03 04:05:07.000 +07:00 -
│ 2001-02-03 04:05:07.000 +07:00
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
│ add workspace 'default'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
│ test-username@host.example.com
│ 2001-02-03 04:05:07.000 +07:00 -
│ 2001-02-03 04:05:07.000 +07:00
│ initialize repo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
"#);
// Nested graph should be wrapped
insta::assert_snapshot!(render(&["op", "log", "--op-diff"], 40, true), @r#"
@ cf25045e0079
│ test-username@host.example.com
│ 2001-02-03 04:05:08.000 +07:00 -
│ 2001-02-03 04:05:08.000 +07:00
│ snapshot working copy
│ args: jj debug snapshot
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm e292def1 (no
│ description set)
│ - qpvuntsm hidden 230dd059 (empty)
│ (no description set)
○ b51416386f26
│ test-username@host.example.com
│ 2001-02-03 04:05:07.000 +07:00 -
│ 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 230dd059 (empty) (no
│ description set)
○ 9a7d829846af
│ test-username@host.example.com
│ 2001-02-03 04:05:07.000 +07:00 -
│ 2001-02-03 04:05:07.000 +07:00
│ initialize repo
│
│ Changed commits:
│ ○ Change zzzzzzzzzzzz
│ + zzzzzzzz 00000000 (empty) (no
│ description set)
○ 000000000000 root()
"#);
// Nested diff stat shouldn't exceed the terminal width
insta::assert_snapshot!(render(&["op", "log", "-n1", "--stat"], 40, true), @r#"
@ cf25045e0079
│ test-username@host.example.com
│ 2001-02-03 04:05:08.000 +07:00 -
│ 2001-02-03 04:05:08.000 +07:00
│ snapshot working copy
│ args: jj debug snapshot
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm e292def1 (no
│ description set)
│ - qpvuntsm hidden 230dd059 (empty)
│ (no description set)
│ file1 | 100 +++++++++++++++++++
│ 1 file changed, 100 insertions(+), 0 deletions(-)
"#);
insta::assert_snapshot!(render(&["op", "log", "-n1", "--no-graph", "--stat"], 40, true), @r#"
cf25045e0079
test-username@host.example.com
2001-02-03 04:05:08.000 +07:00 -
2001-02-03 04:05:08.000 +07:00
snapshot working copy
args: jj debug snapshot
Changed commits:
Change qpvuntsmwlqt
+ qpvuntsm e292def1 (no description set)
- qpvuntsm hidden 230dd059 (empty) (no
description set)
file1 | 100 +++++++++++++++++++++++++
1 file changed, 100 insertions(+), 0 deletions(-)
"#);
// Nested graph widths should be subtracted from the term width
let config = r#"templates.commit_summary='"0 1 2 3 4 5 6 7 8 9"'"#;
insta::assert_snapshot!(
render(&["op", "log", "-T''", "--op-diff", "-n1", "--config-toml", config], 15, true), @r#"
@
│
│ Changed
│ commits:
│ ○ Change
│ qpvuntsmwlqt
│ + 0 1 2 3
│ 4 5 6 7 8
│ 9
│ - 0 1 2 3
│ 4 5 6 7 8
│ 9
"#);
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
}
operations: make hostname and username configurable We currently get the hostname and username from the `whoami` crate. We do that in lib crate, without giving the caller a way to override them. That seems wrong since it might be used in a server and performing operations on behalf of some other user. This commit makes the hostname and username configurable, so the calling crate can pass them in. If they have not been passed in, we still default to the values from the `whoami` crate.
2022-11-13 06:29:06 +00:00
#[test]
fn test_op_log_configurable() {
let test_env = TestEnvironment::default();
test_env.add_config(
tests: pass string instead of bytes to `add_config()` I don't think need to write non-UTF8 bytes to our config files. If we ever do (maybe to test that we give the user a reasonable error message), we add a custom function for that.
2023-01-26 19:26:18 +00:00
r#"operation.hostname = "my-hostname"
operations: make hostname and username configurable We currently get the hostname and username from the `whoami` crate. We do that in lib crate, without giving the caller a way to override them. That seems wrong since it might be used in a server and performing operations on behalf of some other user. This commit makes the hostname and username configurable, so the calling crate can pass them in. If they have not been passed in, we still default to the values from the `whoami` crate.
2022-11-13 06:29:06 +00:00
operation.username = "my-username"
"#,
);
tests: set test hostname and username for operation log This makes the tests more hermetic, even though I don't think the default values (taken from `whoami`) can break any tests (then we would have already seen them break). Now we just need to make the operation log's timestamps predictable and then we can start using operation IDs in snapshot tests.
2022-11-14 07:41:11 +00:00
test_env
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
.jj_cmd(test_env.env_root(), &["git", "init", "repo"])
tests: set test hostname and username for operation log This makes the tests more hermetic, even though I don't think the default values (taken from `whoami`) can break any tests (then we would have already seen them break). Now we just need to make the operation log's timestamps predictable and then we can start using operation IDs in snapshot tests.
2022-11-14 07:41:11 +00:00
.env_remove("JJ_OP_HOSTNAME")
.env_remove("JJ_OP_USERNAME")
.assert()
.success();
operations: make hostname and username configurable We currently get the hostname and username from the `whoami` crate. We do that in lib crate, without giving the caller a way to override them. That seems wrong since it might be used in a server and performing operations on behalf of some other user. This commit makes the hostname and username configurable, so the calling crate can pass them in. If they have not been passed in, we still default to the values from the `whoami` crate.
2022-11-13 06:29:06 +00:00
let repo_path = test_env.env_root().join("repo");
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
assert!(stdout.contains("my-username@my-hostname"));
}
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
#[test]
fn test_op_abandon_ancestors() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 1"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 2"]);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ c2878c428b1c test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
│ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj commit -m 'commit 2'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 5d0ab09ab0fa test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj commit -m 'commit 1'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ add workspace 'default'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
│ initialize repo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
// Abandon old operations. The working-copy operation id should be updated.
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "..@-"]);
insta::assert_snapshot!(stderr, @r###"
op_store: add a virtual root operation, similar to root commit It seems obvious in hindsight to have a virtual root operation just like we have a virtual root commit. It removes the same kind of problems by making sure there's always a common ancestor (or multiple) between any two commits. I think the reason I didn't add a root operation from the beginning was that there used to be a mandatory working-copy commit in the view (this was before support for multiple workspaces). Perhaps we should remove the "initialize repo" operation now. The only difference between their view objects is that the "initialize repo" operation adds the root commit as a head. We could add that to the root operation, but then the root operation's value depends on the commit backend.
2024-01-07 18:32:31 +00:00
Abandoned 3 operations and reparented 1 descendant operations.
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
tests: ensure that operation id is updated by "op abandon" command Before, the test passed even if "op abandon" didn't remap the working-copy operation id.
2024-01-10 08:30:10 +00:00
insta::assert_snapshot!(
cli: rename `jj debug working-copy` to `jj debug local-working-copy` I'd like to add a more generic `jj debug working-copy` command that prints the information that's shared across implementations.
2024-06-28 02:53:20 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Current operation: OperationId("8545e013752445fd845c84eb961dbfbce47e1deb628e4ef20df10f6dc9aae2ef9e47200b0fcc70ca51f050aede05d0fa6dd1db40e20ae740876775738a07d02e")
conflicts: consider the empty tree a non-legacy tree Since we no longer depend on legacy trees being preserved when we build new trees or merge trees, we can consider the root tree a non-legacy tree.
2024-05-26 18:17:12 +00:00
Current tree: Merge(Resolved(TreeId("4b825dc642cb6eb9a060e54bf8d69288fbee4904")))
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 8545e0137524 test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
│ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj commit -m 'commit 2'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
// Abandon operation range.
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 3"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 4"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 5"]);
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "@---..@-"]);
insta::assert_snapshot!(stderr, @r###"
Abandoned 2 operations and reparented 1 descendant operations.
"###);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ d92d0753399f test-username@host.example.com 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00
│ commit c5f7dd51add0046405055336ef443f882a0a8968
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj commit -m 'commit 5'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 8545e0137524 test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
│ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj commit -m 'commit 2'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
// Can't abandon the current operation.
let stderr = test_env.jj_cmd_failure(&repo_path, &["op", "abandon", "..@"]);
insta::assert_snapshot!(stderr, @r###"
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
Error: Cannot abandon the current operation d92d0753399f
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
Hint: Run `jj undo` to revert the current operation, then use `jj op abandon`
"###);
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
// Can't create concurrent abandoned operations explicitly.
cli: exit with CLI error status on "op abandon --at-op" The command option --at-op isn't supported by "op abandon", so it's rather a CLI error.
2024-07-23 04:46:13 +00:00
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["op", "abandon", "--at-op=@-", "@"]);
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
insta::assert_snapshot!(stderr, @r###"
Error: --at-op is not respected
"###);
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
// Abandon the current operation by undoing it first.
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "@-"]);
insta::assert_snapshot!(stderr, @r###"
Abandoned 1 operations and reparented 1 descendant operations.
"###);
tests: ensure that operation id is updated by "op abandon" command Before, the test passed even if "op abandon" didn't remap the working-copy operation id.
2024-01-10 08:30:10 +00:00
insta::assert_snapshot!(
cli: rename `jj debug working-copy` to `jj debug local-working-copy` I'd like to add a more generic `jj debug working-copy` command that prints the information that's shared across implementations.
2024-06-28 02:53:20 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Current operation: OperationId("0699d720d0cecd80fb7d765c45955708c61b12feb1d7ed9ff2777ae719471f04ffed3c1dc24efdbf94bdb74426065d6fa9a4f0862a89db2c8c8e359eefc45462")
conflicts: consider the empty tree a non-legacy tree Since we no longer depend on legacy trees being preserved when we build new trees or merge trees, we can consider the root tree a non-legacy tree.
2024-05-26 18:17:12 +00:00
Current tree: Merge(Resolved(TreeId("4b825dc642cb6eb9a060e54bf8d69288fbee4904")))
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 0699d720d0ce test-username@host.example.com 2001-02-03 04:05:21.000 +07:00 - 2001-02-03 04:05:21.000 +07:00
│ undo operation d92d0753399f732e438bdd88fa7e5214cba2a310d120ec1714028a514c7116bcf04b4a0b26c04dbecf0a917f1d4c8eb05571b8816dd98b0502aaf321e92500b3
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj undo
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 8545e0137524 test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
│ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj commit -m 'commit 2'
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ 000000000000 root()
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
"###);
// Abandon empty range.
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "@-..@-"]);
insta::assert_snapshot!(stderr, @r###"
Nothing changed.
"###);
cli: deprecate `-l` short alias for `--limit` in favour of `-n` This better matches `git log` and affects `jj log`, `jj op log` and `jj obslog`
2024-06-14 23:24:09 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log", "-n1"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 0699d720d0ce test-username@host.example.com 2001-02-03 04:05:21.000 +07:00 - 2001-02-03 04:05:21.000 +07:00
│ undo operation d92d0753399f732e438bdd88fa7e5214cba2a310d120ec1714028a514c7116bcf04b4a0b26c04dbecf0a917f1d4c8eb05571b8816dd98b0502aaf321e92500b3
cli: add "op abandon root..head" command that "reparents" operations In order to implement GC (#12), we'll need to somehow prune old operations. Perhaps the easiest implementation is to just remove unwanted operation files and put tombstone file instead (like git shallow.) However, the removed operations might be referenced by another jj process running in parallel. Since the parallel operation thinks all the historical head commits are reachable, the removed operations would have to be resurrected (or fix up index data, etc.) when the op heads get merged. The idea behind this patch is to split the "op log" GC into two steps: 1. recreate operations to be retained and make the old history unreachable, 2. delete unreachable operations if the head was created e.g. 3 days ago. The latter will be run by "jj util gc". I don't think GC can be implemented 100% safe against lock-less append-only storage, and we'll probably need some timestamp-based mechanism to not remove objects that might be referenced by uncommitted operation. FWIW, another nice thing about this implementation is that the index is automatically invalidated as the op id changes. The bad thing is that the "undo" description would contain an old op id. It seems the performance is pretty okay.
2023-12-29 07:02:56 +00:00
│ args: jj undo
"###);
}
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
#[test]
fn test_op_abandon_without_updating_working_copy() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 1"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 2"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 3"]);
// Abandon without updating the working copy.
let (_stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&["op", "abandon", "@-", "--ignore-working-copy"],
);
insta::assert_snapshot!(stderr, @r###"
Abandoned 1 operations and reparented 1 descendant operations.
"###);
insta::assert_snapshot!(
cli: rename `jj debug working-copy` to `jj debug local-working-copy` I'd like to add a more generic `jj debug working-copy` command that prints the information that's shared across implementations.
2024-06-28 02:53:20 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Current operation: OperationId("cd2b4690faf20cdc477e90c224f15a1f4d62b4d16d0d515fc0f9c998ff91a971cb114d82075c9a7331f3f94d7188c1f93628b7b93e4ca77ac89435a7b536de1e")
conflicts: consider the empty tree a non-legacy tree Since we no longer depend on legacy trees being preserved when we build new trees or merge trees, we can consider the root tree a non-legacy tree.
2024-05-26 18:17:12 +00:00
Current tree: Merge(Resolved(TreeId("4b825dc642cb6eb9a060e54bf8d69288fbee4904")))
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
"###);
insta::assert_snapshot!(
cli: deprecate `-l` short alias for `--limit` in favour of `-n` This better matches `git log` and affects `jj log`, `jj op log` and `jj obslog`
2024-06-14 23:24:09 +00:00
test_env.jj_cmd_success(&repo_path, &["op", "log", "-n1", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 467d42715f00 test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ commit 220cb0b1b5d1c03cc0d351139d824598bb3c1967
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
│ args: jj commit -m 'commit 3'
"###);
// The working-copy operation id isn't updated if it differs from the repo.
// It could be updated if the tree matches, but there's no extra logic for
// that.
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "@-"]);
insta::assert_snapshot!(stderr, @r###"
Abandoned 1 operations and reparented 1 descendant operations.
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Warning: The working copy operation cd2b4690faf2 is not updated because it differs from the repo 467d42715f00.
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
"###);
insta::assert_snapshot!(
cli: rename `jj debug working-copy` to `jj debug local-working-copy` I'd like to add a more generic `jj debug working-copy` command that prints the information that's shared across implementations.
2024-06-28 02:53:20 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Current operation: OperationId("cd2b4690faf20cdc477e90c224f15a1f4d62b4d16d0d515fc0f9c998ff91a971cb114d82075c9a7331f3f94d7188c1f93628b7b93e4ca77ac89435a7b536de1e")
conflicts: consider the empty tree a non-legacy tree Since we no longer depend on legacy trees being preserved when we build new trees or merge trees, we can consider the root tree a non-legacy tree.
2024-05-26 18:17:12 +00:00
Current tree: Merge(Resolved(TreeId("4b825dc642cb6eb9a060e54bf8d69288fbee4904")))
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
"###);
insta::assert_snapshot!(
cli: deprecate `-l` short alias for `--limit` in favour of `-n` This better matches `git log` and affects `jj log`, `jj op log` and `jj obslog`
2024-06-14 23:24:09 +00:00
test_env.jj_cmd_success(&repo_path, &["op", "log", "-n1", "--ignore-working-copy"]), @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ 050b33d674ff test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ commit 220cb0b1b5d1c03cc0d351139d824598bb3c1967
cli: run "op abandon" without loading repo, reject --at-op If indexing failed due to missing commit objects, the repo won't be loadable without --ignore-working-copy (at least in colocated environment.) In that case, we can use "op abandon" to recover, but we had to work around the failed index loading by --ignore-working-copy. Since "op abandon" isn't a repo-level command, it's better to bypass working-copy snapshot and import of git refs at all. --at-op is rejected because it's useless and we'll need extra care for "@" expression resolution and working-copy updates.
2024-01-10 08:20:06 +00:00
│ args: jj commit -m 'commit 3'
"###);
}
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
#[test]
fn test_op_abandon_multiple_heads() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Create 1 base operation + 2 operations to be diverged.
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 1"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 2"]);
test_env.jj_cmd_ok(&repo_path, &["commit", "-m", "commit 3"]);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "log", "--no-graph", r#"-Tid.short() ++ "\n""#],
);
let (head_op_id, prev_op_id) = stdout.lines().next_tuple().unwrap();
insta::assert_snapshot!(head_op_id, @"cd2b4690faf2");
insta::assert_snapshot!(prev_op_id, @"c2878c428b1c");
// Create 1 other concurrent operation.
test_env.jj_cmd_ok(&repo_path, &["commit", "--at-op=@--", "-m", "commit 4"]);
// Can't resolve operation relative to @.
let stderr = test_env.jj_cmd_failure(&repo_path, &["op", "abandon", "@-"]);
insta::assert_snapshot!(stderr, @r###"
Error: The "@" expression resolved to more than one operation
Hint: Try specifying one of the operations by ID: cd2b4690faf2, 603773cdd351
"###);
let (_, other_head_op_id) = stderr.trim_end().rsplit_once(", ").unwrap();
insta::assert_snapshot!(other_head_op_id, @"603773cdd351");
assert_ne!(head_op_id, other_head_op_id);
// Can't abandon one of the head operations.
let stderr = test_env.jj_cmd_failure(&repo_path, &["op", "abandon", head_op_id]);
insta::assert_snapshot!(stderr, @r###"
Error: Cannot abandon the current operation cd2b4690faf2
"###);
// Can't abandon the other head operation.
let stderr = test_env.jj_cmd_failure(&repo_path, &["op", "abandon", other_head_op_id]);
insta::assert_snapshot!(stderr, @r###"
Error: Cannot abandon the current operation 603773cdd351
"###);
// Can abandon the operation which is not an ancestor of the other head.
// This would crash if we attempted to remap the unchanged op in the op
// heads store.
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", prev_op_id]);
insta::assert_snapshot!(stderr, @r###"
Abandoned 1 operations and reparented 2 descendant operations.
"###);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "log"]);
insta::assert_snapshot!(stdout, @r###"
op log: change "resolve concurrent" to "reconcile divergent" "Concurrent" operations are not necessarily actually concurrent, so "divergent" seems like a better name. And "reconcile" seems like a better term for merging them, though we also sometimes use "merge".
2024-08-30 04:59:09 +00:00
@ fb7f33a29cd8 test-username@host.example.com 2001-02-03 04:05:17.000 +07:00 - 2001-02-03 04:05:17.000 +07:00
├─╮ reconcile divergent operations
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
│ │ args: jj op log
○ │ 467d42715f00 test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ │ commit 220cb0b1b5d1c03cc0d351139d824598bb3c1967
│ │ args: jj commit -m 'commit 3'
│ ○ 603773cdd351 test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00
├─╯ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
│ args: jj commit '--at-op=@--' -m 'commit 4'
○ 5d0ab09ab0fa test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj commit -m 'commit 1'
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
insta::assert_snapshot!(stderr, @r###"
Concurrent modification detected, resolving automatically.
"###);
}
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
#[test]
fn test_op_recover_from_bad_gc() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo", "--colocate"]);
let repo_path = test_env.env_root().join("repo");
let git_object_path = |hex: &str| {
let (shard, file_name) = hex.split_at(2);
style: avoid using `.to_owned()`/`.to_vec()` on owned objects `.clone()` is more explicit when we already have an object of the right type.
2024-10-02 20:00:32 +00:00
let mut file_path = repo_path.clone();
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
file_path.extend([".git", "objects", shard, file_name]);
file_path
};
test_env.jj_cmd_ok(&repo_path, &["describe", "-m1"]);
test_env.jj_cmd_ok(&repo_path, &["describe", "-m2"]); // victim
test_env.jj_cmd_ok(&repo_path, &["abandon"]); // break predecessors chain
test_env.jj_cmd_ok(&repo_path, &["new", "-m3"]);
test_env.jj_cmd_ok(&repo_path, &["describe", "-m4"]);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "log", "--no-graph", r#"-Tid.short() ++ "\n""#],
);
let (head_op_id, _, _, bad_op_id) = stdout.lines().next_tuple().unwrap();
insta::assert_snapshot!(head_op_id, @"43d51d9b0c0c");
insta::assert_snapshot!(bad_op_id, @"e02cba71e65d");
// Corrupt the repo by removing hidden but reachable commit object.
let bad_commit_id = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"--at-op",
bad_op_id,
"--no-graph",
"-r@",
"-Tcommit_id",
],
);
insta::assert_snapshot!(bad_commit_id, @"ddf84fc5e0dd314092b3dfb13e09e37fa7d04ef9");
std::fs::remove_file(git_object_path(&bad_commit_id)).unwrap();
// Do concurrent modification to make the situation even worse. At this
// point, the index can be loaded, so this command succeeds.
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
test_env.jj_cmd_ok(&repo_path, &["--at-op=@-", "describe", "-m4.1"]);
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
let stderr =
test_env.jj_cmd_internal_error(&repo_path, &["--at-op", head_op_id, "debug", "reindex"]);
insta::assert_snapshot!(strip_last_line(&stderr), @r###"
Internal error: Failed to index commits at operation e02cba71e65dc9b58bb46e4a31500d94c31ce217f19459883fc85c2d1cfde7124f556565be4f8a3bcd059fe1faee317c3e3eacd3034d419083fd6b85aea396f4
Caused by:
1: Object ddf84fc5e0dd314092b3dfb13e09e37fa7d04ef9 of type commit not found
"###);
// "op log" should still be usable.
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&["op", "log", "--ignore-working-copy", "--at-op", head_op_id],
);
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
insta::assert_snapshot!(stdout, @r###"
@ 43d51d9b0c0c test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00
│ describe commit 37bb762e5dc08073ec4323bdffc023a0f0cc901e
│ args: jj describe -m4
○ 13035304f7d6 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
│ new empty commit
│ args: jj new -m3
○ fcf34f8ae8ac test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ abandon commit ddf84fc5e0dd314092b3dfb13e09e37fa7d04ef9
│ args: jj abandon
○ e02cba71e65d test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
│ describe commit 8b64ddff700dc214dec05d915e85ac692233e6e3
│ args: jj describe -m2
○ 0d7016e495d7 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe -m1
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
insta::assert_snapshot!(stderr, @"");
// "op abandon" should work.
let (_stdout, stderr) =
test_env.jj_cmd_ok(&repo_path, &["op", "abandon", &format!("..{bad_op_id}")]);
insta::assert_snapshot!(stderr, @r###"
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
Abandoned 4 operations and reparented 4 descendant operations.
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
"###);
// The repo should no longer be corrupt.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["log"]);
insta::assert_snapshot!(stdout, @r###"
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
○ mzvwutvl?? test.user@example.com 2001-02-03 08:05:15 dc2c6d52
│ (empty) 4.1
│ @ mzvwutvl?? test.user@example.com 2001-02-03 08:05:12 6d868f04
├─╯ (empty) 4
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
○ zsuskuln test.user@example.com 2001-02-03 08:05:10 HEAD@git f652c321
│ (empty) (no description set)
◆ zzzzzzzz root() 00000000
"###);
cli: make "op abandon" not fail with multiple op heads Since "op abandon" just rewrites DAG, it works no matter if the heads are merged or not. This change will help crash recovery. "op abandon --at-op=<one-of-the-heads>" can't be used because ancestor operations would be preserved by the other head.
2024-07-23 14:15:56 +00:00
insta::assert_snapshot!(stderr, @r###"
Concurrent modification detected, resolving automatically.
"###);
tests: add crash recovery test from bad GC The current "op abandon" and "op log" have workarounds to recover from this situation. Let's make sure they work as expected.
2024-07-22 04:26:43 +00:00
}
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
#[test]
fn test_op_diff() {
let test_env = TestEnvironment::default();
let git_repo_path = test_env.env_root().join("git-repo");
let git_repo = init_bare_git_repo(&git_repo_path);
test_env.jj_cmd_ok(test_env.env_root(), &["git", "clone", "git-repo", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Overview of op log.
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
@ ea112f6a02be test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ check out git remote's default branch
│ args: jj git clone git-repo repo
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ cba9d7096849 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ fetch from git remote into empty repo
│ args: jj git clone git-repo repo
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
// Diff between the same operation should be empty.
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "diff", "--from", "0000000", "--to", "0000000"],
);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 000000000000 root()
To operation 000000000000 root()
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--from", "@", "--to", "@"]);
undo: Report what operation has been undone in `jj op undo`
2024-09-12 14:20:57 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
To operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Diff from parent operation to latest operation.
// `jj op diff --op @` should behave identically to `jj op diff --from
// @- --to @` (if `@` is not a merge commit).
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--from", "@-", "--to", "@"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation cba9d7096849 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 fetch from git remote into empty repo
To operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change sqpuoqvxutmz
+ sqpuoqvx 9708515f (empty) (no description set)
○ Change qpvuntsmwlqt
- qpvuntsm hidden 230dd059 (empty) (no description set)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- (absent)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked ulyvmwyz 1d843d1f bookmark-1 | Commit 1
- untracked ulyvmwyz 1d843d1f bookmark-1 | Commit 1
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let stdout_without_from_to = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
assert_eq!(stdout, stdout_without_from_to);
// Diff from root operation to latest operation
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--from", "0000000"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 000000000000 root()
To operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change sqpuoqvxutmz
│ + sqpuoqvx 9708515f (empty) (no description set)
○ Change ulyvmwyzwuwt
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
│ + ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ ○ Change tqyxmsztkvot
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
├─╯ + tqyxmszt 3e785984 bookmark-3@origin | Commit 3
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ ○ Change yuvsmzqkmpws
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
├─╯ + yuvsmzqk 3d9189bc bookmark-2@origin | Commit 2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
○ Change zzzzzzzzzzzz
+ zzzzzzzz 00000000 (empty) (no description set)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- (absent)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ untracked yuvsmzqk 3d9189bc bookmark-2@origin | Commit 2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-3@origin:
+ untracked tqyxmszt 3e785984 bookmark-3@origin | Commit 3
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Diff from latest operation to root operation
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--to", "0000000"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
To operation 000000000000 root()
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change sqpuoqvxutmz
│ - sqpuoqvx hidden 9708515f (empty) (no description set)
○ Change ulyvmwyzwuwt
│ - ulyvmwyz hidden 1d843d1f Commit 1
│ ○ Change tqyxmsztkvot
├─╯ - tqyxmszt hidden 3e785984 Commit 3
│ ○ Change yuvsmzqkmpws
├─╯ - yuvsmzqk hidden 3d9189bc Commit 2
○ Change zzzzzzzzzzzz
- zzzzzzzz hidden 00000000 (empty) (no description set)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ (absent)
- ulyvmwyz hidden 1d843d1f Commit 1
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- tracked ulyvmwyz hidden 1d843d1f Commit 1
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- untracked yuvsmzqk hidden 3d9189bc Commit 2
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-3@origin:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- untracked tqyxmszt hidden 3e785984 Commit 3
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Create a conflicted bookmark using a concurrent operation.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
test_env.jj_cmd_ok(
&repo_path,
&[
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark",
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"set",
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark-1",
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"-r",
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark-2@origin",
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"--at-op",
"@-",
],
);
let (_, stderr) = test_env.jj_cmd_ok(&repo_path, &["log"]);
insta::assert_snapshot!(&stderr, @r###"
Concurrent modification detected, resolving automatically.
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
@ f534dfc3151b test-username@host.example.com 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00
op log: change "resolve concurrent" to "reconcile divergent" "Concurrent" operations are not necessarily actually concurrent, so "divergent" seems like a better name. And "reconcile" seems like a better term for merging them, though we also sometimes use "merge".
2024-08-30 04:59:09 +00:00
├─╮ reconcile divergent operations
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ │ args: jj log
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ │ ea112f6a02be test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ │ check out git remote's default branch
│ │ args: jj git clone git-repo repo
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
│ ○ 9ded7e2755e1 test-username@host.example.com 2001-02-03 04:05:15.000 +07:00 - 2001-02-03 04:05:15.000 +07:00
├─╯ point bookmark bookmark-1 to commit 3d9189bc56a1972729350456eb95ec5bf90be2a8
│ args: jj bookmark set bookmark-1 -r bookmark-2@origin --at-op @-
○ cba9d7096849 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
│ fetch from git remote into empty repo
│ args: jj git clone git-repo repo
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
let op_log_lines = stdout.lines().collect_vec();
let op_id = op_log_lines[0].split(' ').nth(4).unwrap();
let first_parent_id = op_log_lines[3].split(' ').nth(3).unwrap();
let second_parent_id = op_log_lines[6].split(' ').nth(3).unwrap();
// Diff between the first parent of the merge operation and the merge operation.
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "diff", "--from", first_parent_id, "--to", op_id],
);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation ea112f6a02be 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 check out git remote's default branch
To operation f534dfc3151b 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00 reconcile divergent operations
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ (added) ulyvmwyz 1d843d1f bookmark-1?? bookmark-1@origin | Commit 1
+ (added) yuvsmzqk 3d9189bc bookmark-1?? bookmark-2@origin | Commit 2
- ulyvmwyz 1d843d1f bookmark-1?? bookmark-1@origin | Commit 1
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Diff between the second parent of the merge operation and the merge
// operation.
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "diff", "--from", second_parent_id, "--to", op_id],
);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 9ded7e2755e1 2001-02-03 04:05:15.000 +07:00 - 2001-02-03 04:05:15.000 +07:00 point bookmark bookmark-1 to commit 3d9189bc56a1972729350456eb95ec5bf90be2a8
To operation f534dfc3151b 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00 reconcile divergent operations
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change sqpuoqvxutmz
+ sqpuoqvx 9708515f (empty) (no description set)
○ Change qpvuntsmwlqt
- qpvuntsm hidden 230dd059 (empty) (no description set)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ (added) ulyvmwyz 1d843d1f bookmark-1?? bookmark-1@origin | Commit 1
+ (added) yuvsmzqk 3d9189bc bookmark-1?? bookmark-2@origin | Commit 2
- yuvsmzqk 3d9189bc bookmark-1?? bookmark-2@origin | Commit 2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked ulyvmwyz 1d843d1f bookmark-1?? bookmark-1@origin | Commit 1
- untracked ulyvmwyz 1d843d1f bookmark-1?? bookmark-1@origin | Commit 1
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Test fetching from git remote.
modify_git_repo(git_repo);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["git", "fetch"]);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
bookmark: bookmark-1@origin [updated] tracked
bookmark: bookmark-2@origin [updated] untracked
bookmark: bookmark-3@origin [deleted] untracked
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Abandoned 1 commits that are no longer reachable.
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation f534dfc3151b 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00 reconcile divergent operations
To operation 8a21e297a587 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07:00 fetch from git remote(s) origin
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change qzxslznxxpoz
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ qzxslznx d487febd bookmark-2@origin | Commit 5
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
○ Change slvtnnzxztqy
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
○ Change tqyxmsztkvot
- tqyxmszt hidden 3e785984 Commit 3
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ (added) slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
+ (added) yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- (added) ulyvmwyz 1d843d1f Commit 1
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
- (added) yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- tracked ulyvmwyz 1d843d1f Commit 1
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ untracked qzxslznx d487febd bookmark-2@origin | Commit 5
- untracked yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
bookmark-3@origin:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- untracked tqyxmszt hidden 3e785984 Commit 3
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test creation of bookmark.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
&[
"bookmark",
"create",
"bookmark-2",
"-r",
"bookmark-2@origin",
],
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Created 1 bookmarks pointing to qzxslznx d487febd bookmark-2 bookmark-2@origin | Commit 5
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 8a21e297a587 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07:00 fetch from git remote(s) origin
To operation ef314062f7f5 2001-02-03 04:05:22.000 +07:00 - 2001-02-03 04:05:22.000 +07:00 create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2:
+ qzxslznx d487febd bookmark-2 bookmark-2@origin | Commit 5
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- (absent)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test tracking of bookmark.
let (stdout, stderr) =
test_env.jj_cmd_ok(&repo_path, &["bookmark", "track", "bookmark-2@origin"]);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"###);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Started tracking 1 remote bookmarks.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation ef314062f7f5 2001-02-03 04:05:22.000 +07:00 - 2001-02-03 04:05:22.000 +07:00 create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
To operation bc306c9bb67f 2001-02-03 04:05:24.000 +07:00 - 2001-02-03 04:05:24.000 +07:00 track remote bookmark bookmark-2@origin
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ tracked qzxslznx d487febd bookmark-2 | Commit 5
- untracked qzxslznx d487febd bookmark-2 | Commit 5
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Test creation of new commit.
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test tracking of bookmark.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let (stdout, stderr) =
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_ok(&repo_path, &["bookmark", "track", "bookmark-2@origin"]);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Warning: Remote bookmark already tracked: bookmark-2@origin
Nothing changed.
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation ef314062f7f5 2001-02-03 04:05:22.000 +07:00 - 2001-02-03 04:05:22.000 +07:00 create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
To operation bc306c9bb67f 2001-02-03 04:05:24.000 +07:00 - 2001-02-03 04:05:24.000 +07:00 track remote bookmark bookmark-2@origin
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ tracked qzxslznx d487febd bookmark-2 | Commit 5
- untracked qzxslznx d487febd bookmark-2 | Commit 5
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test creation of new commit.
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&["new", "bookmark-1@origin", "-m", "new commit"],
);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: wvuyspvk 358b82d6 (empty) new commit
Parent commit : slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Added 1 files, modified 0 files, removed 1 files
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation bc306c9bb67f 2001-02-03 04:05:24.000 +07:00 - 2001-02-03 04:05:24.000 +07:00 track remote bookmark bookmark-2@origin
To operation 1ae777a7acc8 2001-02-03 04:05:28.000 +07:00 - 2001-02-03 04:05:28.000 +07:00 new empty commit
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ Change wvuyspvkupzz
+ wvuyspvk 358b82d6 (empty) new commit
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
○ Change sqpuoqvxutmz
- sqpuoqvx hidden 9708515f (empty) (no description set)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test updating of local bookmark.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let (stdout, stderr) =
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_ok(&repo_path, &["bookmark", "set", "bookmark-1", "-r", "@"]);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Moved 1 bookmarks to wvuyspvk 358b82d6 bookmark-1* | (empty) new commit
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 1ae777a7acc8 2001-02-03 04:05:28.000 +07:00 - 2001-02-03 04:05:28.000 +07:00 new empty commit
To operation 5728693d7de3 2001-02-03 04:05:30.000 +07:00 - 2001-02-03 04:05:30.000 +07:00 point bookmark bookmark-1 to commit 358b82d6be53fa9b062325abb8bc820a8b34c68d
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ wvuyspvk 358b82d6 bookmark-1* | (empty) new commit
- (added) slvtnnzx 4f856199 bookmark-1@origin | Commit 4
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- (added) yuvsmzqk 3d9189bc Commit 2
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test deletion of local bookmark.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["bookmark", "delete", "bookmark-2"]);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Deleted 1 bookmarks.
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 5728693d7de3 2001-02-03 04:05:30.000 +07:00 - 2001-02-03 04:05:30.000 +07:00 point bookmark bookmark-1 to commit 358b82d6be53fa9b062325abb8bc820a8b34c68d
To operation 0f77d601f1cd 2001-02-03 04:05:32.000 +07:00 - 2001-02-03 04:05:32.000 +07:00 delete bookmark bookmark-2
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
- qzxslznx d487febd bookmark-2@origin | Commit 5
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Test pushing to Git remote.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["git", "push", "--tracked"]);
insta::assert_snapshot!(&stdout, @r###"
"###);
git-push: just say "Changes to push to <REMOTE>" "Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here is redundant. If we add support for pushing tags, this message will have to be generalized anyway.
2024-09-14 02:47:03 +00:00
insta::assert_snapshot!(&stderr, @r#"
Changes to push to origin:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Move forward bookmark bookmark-1 from 4f856199edbf to 358b82d6be53
Delete bookmark bookmark-2 from d487febd08e6
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Warning: The working-copy commit in workspace 'default' became immutable, so a new commit has been created on top of it.
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Working copy now at: oupztwtk 2f0718a0 (empty) (no description set)
Parent commit : wvuyspvk 358b82d6 bookmark-1 | (empty) new commit
git-push: just say "Changes to push to <REMOTE>" "Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here is redundant. If we add support for pushing tags, this message will have to be generalized anyway.
2024-09-14 02:47:03 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 0f77d601f1cd 2001-02-03 04:05:32.000 +07:00 - 2001-02-03 04:05:32.000 +07:00 delete bookmark bookmark-2
To operation 65409e59d36a 2001-02-03 04:05:34.000 +07:00 - 2001-02-03 04:05:34.000 +07:00 push all tracked bookmarks to git remote origin
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ Change oupztwtkortx
+ oupztwtk 2f0718a0 (empty) (no description set)
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked wvuyspvk 358b82d6 bookmark-1 | (empty) new commit
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
- tracked slvtnnzx 4f856199 Commit 4
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- tracked qzxslznx d487febd Commit 5
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
}
#[test]
fn test_op_diff_patch() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Update working copy with a single file and create new commit.
std::fs::write(repo_path.join("file"), "a\n").unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["new"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: rlvkpnrz 56950632 (empty) (no description set)
Parent commit : qpvuntsm 6b1027d2 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--op", "@-", "-p", "--git"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation b51416386f26 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 add workspace 'default'
To operation 6188e9d1f7da 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00 snapshot working copy
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change qpvuntsmwlqt
+ qpvuntsm 6b1027d2 (no description set)
- qpvuntsm hidden 230dd059 (empty) (no description set)
diff --git a/file b/file
new file mode 100644
index 0000000000..7898192261
--- /dev/null
+++ b/file
@@ -1,0 +1,1 @@
+a
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "--op", "@", "-p", "--git"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 6188e9d1f7da 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00 snapshot working copy
To operation 8f6a879bef11 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00 new empty commit
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change rlvkpnrzqnoo
+ rlvkpnrz 56950632 (empty) (no description set)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Squash the working copy commit.
std::fs::write(repo_path.join("file"), "b\n").unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["squash"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: mzvwutvl 9f4fb57f (empty) (no description set)
Parent commit : qpvuntsm 2ac85fd1 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "-p", "--git"]);
undo: Report what operation has been undone in `jj op undo`
2024-09-12 14:20:57 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 874d3a8b4c77 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00 snapshot working copy
To operation c53f5f1afbc6 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00 squash commits into 6b1027d2770cd0a39c468e525e52bf8c47e1464a
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change mzvwutvlkqwt
│ + mzvwutvl 9f4fb57f (empty) (no description set)
│ ○ Change rlvkpnrzqnoo
├─╯ - rlvkpnrz hidden 1d7f8f94 (no description set)
│ diff --git a/file b/file
│ index 7898192261..6178079822 100644
│ --- a/file
│ +++ b/file
│ @@ -1,1 +1,1 @@
│ -a
│ +b
○ Change qpvuntsmwlqt
+ qpvuntsm 2ac85fd1 (no description set)
- qpvuntsm hidden 6b1027d2 (no description set)
diff --git a/file b/file
index 7898192261..6178079822 100644
--- a/file
+++ b/file
@@ -1,1 +1,1 @@
-a
+b
undo: Report what operation has been undone in `jj op undo`
2024-09-12 14:20:57 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// Abandon the working copy commit.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["abandon"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Abandoned commit mzvwutvl 9f4fb57f (empty) (no description set)
Working copy now at: yqosqzyt 33f321c4 (empty) (no description set)
Parent commit : qpvuntsm 2ac85fd1 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "diff", "-p", "--git"]);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation c53f5f1afbc6 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00 squash commits into 6b1027d2770cd0a39c468e525e52bf8c47e1464a
To operation e13dc1c7a3b3 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07:00 abandon commit 9f4fb57fba25a7b47ce5980a5d9a4766778331e8
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
Changed commits:
○ Change yqosqzytrlsw
+ yqosqzyt 33f321c4 (empty) (no description set)
○ Change mzvwutvlkqwt
- mzvwutvl hidden 9f4fb57f (empty) (no description set)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
}
op diff: pass merged repo in to DiffRenderer Since DiffRenderer borrows a repo, it shouldn't be constructed from the base WorkspaceCommandHelper.
2024-09-05 09:26:11 +00:00
#[test]
fn test_op_diff_sibling() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "log", "--no-graph", r#"-Tid.short() ++ "\n""#],
);
let base_op_id = stdout.lines().next().unwrap();
insta::assert_snapshot!(base_op_id, @"b51416386f26");
// Create merge commit at one operation side. The parent trees will have to
// be merged when diffing, which requires the commit index of this side.
test_env.jj_cmd_ok(&repo_path, &["new", "root()", "-mA.1"]);
std::fs::write(repo_path.join("file1"), "a\n").unwrap();
test_env.jj_cmd_ok(&repo_path, &["new", "root()", "-mA.2"]);
std::fs::write(repo_path.join("file2"), "a\n").unwrap();
test_env.jj_cmd_ok(&repo_path, &["new", "all:@-+", "-mA"]);
// Create another operation diverged from the base operation.
test_env.jj_cmd_ok(&repo_path, &["describe", "--at-op", base_op_id, "-mB"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "log"]);
insta::assert_snapshot!(&stdout, @r###"
@ 2629707e5305 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07:00
├─╮ reconcile divergent operations
│ │ args: jj op log
○ │ b8584dcdb220 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
│ │ new empty commit
│ │ args: jj new 'all:@-+' -mA
○ │ f0bb05eb2e7e test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
│ │ snapshot working copy
│ │ args: jj new 'all:@-+' -mA
○ │ ee4ec332e269 test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ │ new empty commit
│ │ args: jj new 'root()' -mA.2
○ │ 971683f333fa test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
│ │ snapshot working copy
│ │ args: jj new 'root()' -mA.2
○ │ 3df45c2cdcb4 test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
│ │ new empty commit
│ │ args: jj new 'root()' -mA.1
│ ○ 654f3215449e test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00
├─╯ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe --at-op b51416386f26 -mB
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
insta::assert_snapshot!(&stderr, @r###"
Concurrent modification detected, resolving automatically.
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["op", "log", "--no-graph", r#"-Tid.short() ++ "\n""#],
);
let (head_op_id, p1_op_id, _, _, _, _, p2_op_id) = stdout.lines().next_tuple().unwrap();
insta::assert_snapshot!(head_op_id, @"2629707e5305");
insta::assert_snapshot!(p1_op_id, @"b8584dcdb220");
insta::assert_snapshot!(p2_op_id, @"654f3215449e");
// Diff between p1 and p2 operations should work no matter if p2 is chosen
// as a base operation.
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"diff",
"--at-op",
p1_op_id,
"--from",
p1_op_id,
"--to",
p2_op_id,
"--summary",
],
);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation b8584dcdb220 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00 new empty commit
To operation 654f3215449e 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00 describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
op diff: pass merged repo in to DiffRenderer Since DiffRenderer borrows a repo, it shouldn't be constructed from the base WorkspaceCommandHelper.
2024-09-05 09:26:11 +00:00
Changed commits:
○ Change qpvuntsmwlqt
+ qpvuntsm 02ef2bc4 (empty) B
○ Change mzvwutvlkqwt
├─╮ - mzvwutvl hidden 270db3d9 (empty) A
│ ○ Change kkmpptxzrspx
│ - kkmpptxz hidden 8331e0a3 A.1
│ A file1
○ Change zsuskulnrvyr
- zsuskuln hidden 8afecaef A.2
A file2
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
op diff: pass merged repo in to DiffRenderer Since DiffRenderer borrows a repo, it shouldn't be constructed from the base WorkspaceCommandHelper.
2024-09-05 09:26:11 +00:00
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"diff",
"--at-op",
p2_op_id,
"--from",
p2_op_id,
"--to",
p1_op_id,
"--summary",
],
);
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(&stdout, @r#"
From operation 654f3215449e 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00 describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
To operation b8584dcdb220 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00 new empty commit
op diff: pass merged repo in to DiffRenderer Since DiffRenderer borrows a repo, it shouldn't be constructed from the base WorkspaceCommandHelper.
2024-09-05 09:26:11 +00:00
Changed commits:
○ Change mzvwutvlkqwt
├─╮ + mzvwutvl 270db3d9 (empty) A
│ ○ Change kkmpptxzrspx
│ + kkmpptxz 8331e0a3 A.1
│ A file1
○ Change zsuskulnrvyr
+ zsuskuln 8afecaef A.2
A file2
○ Change qpvuntsmwlqt
- qpvuntsm hidden 02ef2bc4 (empty) B
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
op diff: pass merged repo in to DiffRenderer Since DiffRenderer borrows a repo, it shouldn't be constructed from the base WorkspaceCommandHelper.
2024-09-05 09:26:11 +00:00
}
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
#[test]
fn test_op_diff_word_wrap() {
let test_env = TestEnvironment::default();
let git_repo_path = test_env.env_root().join("git-repo");
init_bare_git_repo(&git_repo_path);
test_env.jj_cmd_ok(test_env.env_root(), &["git", "clone", "git-repo", "repo"]);
let repo_path = test_env.env_root().join("repo");
let render = |args: &[&str], columns: u32, word_wrap: bool| {
let mut args = args.to_vec();
if word_wrap {
args.push("--config-toml=ui.log-word-wrap=true");
}
let assert = test_env
.jj_cmd(&repo_path, &args)
.env("COLUMNS", columns.to_string())
.assert()
.success()
.stderr("");
get_stdout_string(&assert)
};
// Add some file content changes
std::fs::write(repo_path.join("file1"), "foo\n".repeat(100)).unwrap();
test_env.jj_cmd_ok(&repo_path, &["debug", "snapshot"]);
// ui.log-word-wrap option works, and diff stat respects content width
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
insta::assert_snapshot!(render(&["op", "diff", "--from=@---", "--stat"], 40, true), @r#"
From operation b51416386f26 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 add workspace 'default'
To operation d12081b11443 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00 snapshot working copy
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
Changed commits:
○ Change sqpuoqvxutmz
│ + sqpuoqvx 850efc9e (no description
│ set)
│ file1 | 100 ++++++++++++++++++++++
│ 1 file changed, 100 insertions(+), 0 deletions(-)
○ Change ulyvmwyzwuwt
+ ulyvmwyz 1d843d1f bookmark-1 |
Commit 1
some-file | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
○ Change tqyxmsztkvot
+ tqyxmszt 3e785984 bookmark-3@origin
| Commit 3
some-file | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
○ Change yuvsmzqkmpws
+ yuvsmzqk 3d9189bc bookmark-2@origin
| Commit 2
some-file | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
○ Change qpvuntsmwlqt
- qpvuntsm hidden 230dd059 (empty)
(no description set)
0 files changed, 0 insertions(+), 0 deletions(-)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
bookmark-1:
+ ulyvmwyz 1d843d1f bookmark-1 | Commit
1
- (absent)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
bookmark-1@origin:
+ tracked ulyvmwyz 1d843d1f bookmark-1 |
Commit 1
- untracked (absent)
bookmark-2@origin:
+ untracked yuvsmzqk 3d9189bc
bookmark-2@origin | Commit 2
- untracked (absent)
bookmark-3@origin:
+ untracked tqyxmszt 3e785984
bookmark-3@origin | Commit 3
- untracked (absent)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
// Graph width should be subtracted from the term width
let config = r#"templates.commit_summary='"0 1 2 3 4 5 6 7 8 9"'"#;
insta::assert_snapshot!(
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
render(&["op", "diff", "--from=@---", "--config-toml", config], 10, true), @r#"
From operation b51416386f26 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00 add workspace 'default'
To operation d12081b11443 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00 snapshot working copy
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
Changed
commits:
○ Change
│ sqpuoqvxutmz
│ + 0 1 2
│ 3 4 5 6
│ 7 8 9
○ Change
ulyvmwyzwuwt
+ 0 1 2
3 4 5 6
7 8 9
○ Change
tqyxmsztkvot
+ 0 1 2
3 4 5 6
7 8 9
○ Change
yuvsmzqkmpws
+ 0 1 2
3 4 5 6
7 8 9
○ Change
qpvuntsmwlqt
- 0 1 2
3 4 5 6
7 8 9
Changed
local
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
bookmarks:
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
bookmark-1:
+ 0 1 2 3
4 5 6 7 8
9
- (absent)
Changed
remote
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
bookmarks:
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
bookmark-1@origin:
+ tracked
0 1 2 3 4
5 6 7 8 9
-
untracked
(absent)
bookmark-2@origin:
+
untracked
0 1 2 3 4
5 6 7 8 9
-
untracked
(absent)
bookmark-3@origin:
+
untracked
0 1 2 3 4
5 6 7 8 9
-
untracked
(absent)
op-diff: Use op_summary template
2024-09-13 11:25:58 +00:00
"#);
op diff: apply word wrapping to non-graph template outputs These contents may be embedded in "op log", and it's probably good to enable word wrapping consistently.
2024-09-03 08:58:46 +00:00
}
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
#[test]
fn test_op_show() {
let test_env = TestEnvironment::default();
let git_repo_path = test_env.env_root().join("git-repo");
let git_repo = init_bare_git_repo(&git_repo_path);
test_env.jj_cmd_ok(test_env.env_root(), &["git", "clone", "git-repo", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Overview of op log.
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
@ ea112f6a02be test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
│ check out git remote's default branch
│ args: jj git clone git-repo repo
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ cba9d7096849 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
│ fetch from git remote into empty repo
│ args: jj git clone git-repo repo
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
○ 000000000000 root()
"###);
// The root operation is empty.
op show: accept root operation by mapping empty parents to root I'm thinking of adding an option to embed operation diffs in "op log", and "op log" shouldn't fail at the root operation. Let's make "op diff"/"show" also work for consistency.
2024-09-06 05:36:01 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "0000000"]);
insta::assert_snapshot!(&stdout, @r###"
000000000000 root()
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
// Showing the latest operation.
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "@"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
ea112f6a02be test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
check out git remote's default branch
args: jj git clone git-repo repo
Changed commits:
○ Change sqpuoqvxutmz
+ sqpuoqvx 9708515f (empty) (no description set)
○ Change qpvuntsmwlqt
- qpvuntsm hidden 230dd059 (empty) (no description set)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- (absent)
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked ulyvmwyz 1d843d1f bookmark-1 | Commit 1
- untracked ulyvmwyz 1d843d1f bookmark-1 | Commit 1
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
// `jj op show @` should behave identically to `jj op show`.
let stdout_without_op_id = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
assert_eq!(stdout, stdout_without_op_id);
// Showing a given operation.
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "@-"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
cba9d7096849 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
fetch from git remote into empty repo
args: jj git clone git-repo repo
Changed commits:
○ Change tqyxmsztkvot
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ tqyxmszt 3e785984 bookmark-3@origin | Commit 3
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
○ Change yuvsmzqkmpws
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ yuvsmzqk 3d9189bc bookmark-2@origin | Commit 2
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
○ Change ulyvmwyzwuwt
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ ulyvmwyz 1d843d1f bookmark-1@origin | Commit 1
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ untracked ulyvmwyz 1d843d1f bookmark-1@origin | Commit 1
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ untracked yuvsmzqk 3d9189bc bookmark-2@origin | Commit 2
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-3@origin:
+ untracked tqyxmszt 3e785984 bookmark-3@origin | Commit 3
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- untracked (absent)
"###);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Create a conflicted bookmark using a concurrent operation.
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
test_env.jj_cmd_ok(
&repo_path,
&[
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark",
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"set",
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark-1",
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"-r",
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"bookmark-2@origin",
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"--at-op",
"@-",
],
);
let (_, stderr) = test_env.jj_cmd_ok(&repo_path, &["log"]);
insta::assert_snapshot!(&stderr, @r###"
Concurrent modification detected, resolving automatically.
"###);
// Showing a merge operation is empty.
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
5d52ce7672bb test-username@host.example.com 2001-02-03 04:05:14.000 +07:00 - 2001-02-03 04:05:14.000 +07:00
op log: change "resolve concurrent" to "reconcile divergent" "Concurrent" operations are not necessarily actually concurrent, so "divergent" seems like a better name. And "reconcile" seems like a better term for merging them, though we also sometimes use "merge".
2024-08-30 04:59:09 +00:00
reconcile divergent operations
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
args: jj log
"###);
// Test fetching from git remote.
modify_git_repo(git_repo);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["git", "fetch"]);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
bookmark: bookmark-1@origin [updated] tracked
bookmark: bookmark-2@origin [updated] untracked
bookmark: bookmark-3@origin [deleted] untracked
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
Abandoned 1 commits that are no longer reachable.
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
5eed0f5f5fbc test-username@host.example.com 2001-02-03 04:05:16.000 +07:00 - 2001-02-03 04:05:16.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
fetch from git remote(s) origin
args: jj git fetch
Changed commits:
○ Change qzxslznxxpoz
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ qzxslznx d487febd bookmark-2@origin | Commit 5
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
○ Change slvtnnzxztqy
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
+ slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
○ Change tqyxmsztkvot
- tqyxmszt hidden 3e785984 Commit 3
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ (added) slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
+ (added) yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- (added) ulyvmwyz 1d843d1f Commit 1
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
- (added) yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- tracked ulyvmwyz 1d843d1f Commit 1
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ untracked qzxslznx d487febd bookmark-2@origin | Commit 5
- untracked yuvsmzqk 3d9189bc bookmark-1?? | Commit 2
bookmark-3@origin:
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- untracked tqyxmszt hidden 3e785984 Commit 3
"###);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test creation of bookmark.
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
&[
"bookmark",
"create",
"bookmark-2",
"-r",
"bookmark-2@origin",
],
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Created 1 bookmarks pointing to qzxslznx d487febd bookmark-2 bookmark-2@origin | Commit 5
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
25b687bb01b6 test-username@host.example.com 2001-02-03 04:05:18.000 +07:00 - 2001-02-03 04:05:18.000 +07:00
create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
args: jj bookmark create bookmark-2 -r bookmark-2@origin
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2:
+ qzxslznx d487febd bookmark-2 bookmark-2@origin | Commit 5
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- (absent)
"###);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test tracking of a bookmark.
let (stdout, stderr) =
test_env.jj_cmd_ok(&repo_path, &["bookmark", "track", "bookmark-2@origin"]);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
"###);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Started tracking 1 remote bookmarks.
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
48cf434c463d test-username@host.example.com 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07:00
track remote bookmark bookmark-2@origin
args: jj bookmark track bookmark-2@origin
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ tracked qzxslznx d487febd bookmark-2 | Commit 5
- untracked qzxslznx d487febd bookmark-2 | Commit 5
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
// Test creation of new commit.
let (stdout, stderr) =
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_ok(&repo_path, &["bookmark", "track", "bookmark-2@origin"]);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Warning: Remote bookmark already tracked: bookmark-2@origin
Nothing changed.
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
48cf434c463d test-username@host.example.com 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07:00
track remote bookmark bookmark-2@origin
args: jj bookmark track bookmark-2@origin
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
+ tracked qzxslznx d487febd bookmark-2 | Commit 5
- untracked qzxslznx d487febd bookmark-2 | Commit 5
"###);
// Test creation of new commit.
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&["new", "bookmark-1@origin", "-m", "new commit"],
);
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: xznxytkn eb6c2b21 (empty) new commit
Parent commit : slvtnnzx 4f856199 bookmark-1?? bookmark-1@origin | Commit 4
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
Added 1 files, modified 0 files, removed 1 files
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
89aa6cca51fc test-username@host.example.com 2001-02-03 04:05:24.000 +07:00 - 2001-02-03 04:05:24.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
new empty commit
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
args: jj new bookmark-1@origin -m 'new commit'
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
Changed commits:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ Change xznxytknoqwo
+ xznxytkn eb6c2b21 (empty) new commit
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
○ Change sqpuoqvxutmz
- sqpuoqvx hidden 9708515f (empty) (no description set)
"###);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test updating of local bookmark.
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
let (stdout, stderr) =
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_ok(&repo_path, &["bookmark", "set", "bookmark-1", "-r", "@"]);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Moved 1 bookmarks to xznxytkn eb6c2b21 bookmark-1* | (empty) new commit
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
6d6bf9b35d8a test-username@host.example.com 2001-02-03 04:05:26.000 +07:00 - 2001-02-03 04:05:26.000 +07:00
point bookmark bookmark-1 to commit eb6c2b21ec20a33ab6a1c44bc86c59d84ffd93ac
args: jj bookmark set bookmark-1 -r @
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1:
+ xznxytkn eb6c2b21 bookmark-1* | (empty) new commit
- (added) slvtnnzx 4f856199 bookmark-1@origin | Commit 4
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- (added) yuvsmzqk 3d9189bc Commit 2
"###);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
// Test deletion of local bookmark.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["bookmark", "delete", "bookmark-2"]);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
insta::assert_snapshot!(&stdout, @r###"
"###);
insta::assert_snapshot!(&stderr, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Deleted 1 bookmarks.
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
a50c95a6b180 test-username@host.example.com 2001-02-03 04:05:28.000 +07:00 - 2001-02-03 04:05:28.000 +07:00
delete bookmark bookmark-2
args: jj bookmark delete bookmark-2
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed local bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2:
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
+ (absent)
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
- qzxslznx d487febd bookmark-2@origin | Commit 5
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
"###);
// Test pushing to Git remote.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["git", "push", "--tracked"]);
insta::assert_snapshot!(&stdout, @r###"
"###);
git-push: just say "Changes to push to <REMOTE>" "Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here is redundant. If we add support for pushing tags, this message will have to be generalized anyway.
2024-09-14 02:47:03 +00:00
insta::assert_snapshot!(&stderr, @r#"
Changes to push to origin:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Move forward bookmark bookmark-1 from 4f856199edbf to eb6c2b21ec20
Delete bookmark bookmark-2 from d487febd08e6
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
Warning: The working-copy commit in workspace 'default' became immutable, so a new commit has been created on top of it.
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Working copy now at: pzsxstzt 7ab2d837 (empty) (no description set)
Parent commit : xznxytkn eb6c2b21 bookmark-1 | (empty) new commit
git-push: just say "Changes to push to <REMOTE>" "Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here is redundant. If we add support for pushing tags, this message will have to be generalized anyway.
2024-09-14 02:47:03 +00:00
"#);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show"]);
insta::assert_snapshot!(&stdout, @r###"
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
5d994bb7d230 test-username@host.example.com 2001-02-03 04:05:30.000 +07:00 - 2001-02-03 04:05:30.000 +07:00
push all tracked bookmarks to git remote origin
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
args: jj git push --tracked
Changed commits:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
○ Change pzsxstztnpkv
+ pzsxstzt 7ab2d837 (empty) (no description set)
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
bookmarks: update some leftover uses of the word "branch"
2024-09-11 16:11:50 +00:00
Changed remote bookmarks:
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-1@origin:
+ tracked xznxytkn eb6c2b21 bookmark-1 | (empty) new commit
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
- tracked slvtnnzx 4f856199 Commit 4
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
bookmark-2@origin:
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
+ untracked (absent)
- tracked qzxslznx d487febd Commit 5
"###);
}
#[test]
fn test_op_show_patch() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Update working copy with a single file and create new commit.
std::fs::write(repo_path.join("file"), "a\n").unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["new"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: rlvkpnrz 56950632 (empty) (no description set)
Parent commit : qpvuntsm 6b1027d2 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "@-", "-p", "--git"]);
insta::assert_snapshot!(&stdout, @r###"
6188e9d1f7da test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
snapshot working copy
args: jj new
Changed commits:
○ Change qpvuntsmwlqt
+ qpvuntsm 6b1027d2 (no description set)
- qpvuntsm hidden 230dd059 (empty) (no description set)
diff --git a/file b/file
new file mode 100644
index 0000000000..7898192261
--- /dev/null
+++ b/file
@@ -1,0 +1,1 @@
+a
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "@", "-p", "--git"]);
insta::assert_snapshot!(&stdout, @r###"
8f6a879bef11 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
new empty commit
args: jj new
Changed commits:
○ Change rlvkpnrzqnoo
+ rlvkpnrz 56950632 (empty) (no description set)
"###);
// Squash the working copy commit.
std::fs::write(repo_path.join("file"), "b\n").unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["squash"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Working copy now at: mzvwutvl 9f4fb57f (empty) (no description set)
Parent commit : qpvuntsm 2ac85fd1 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "-p", "--git"]);
insta::assert_snapshot!(&stdout, @r###"
c53f5f1afbc6 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
squash commits into 6b1027d2770cd0a39c468e525e52bf8c47e1464a
args: jj squash
Changed commits:
○ Change mzvwutvlkqwt
│ + mzvwutvl 9f4fb57f (empty) (no description set)
│ ○ Change rlvkpnrzqnoo
├─╯ - rlvkpnrz hidden 1d7f8f94 (no description set)
│ diff --git a/file b/file
│ index 7898192261..6178079822 100644
│ --- a/file
│ +++ b/file
│ @@ -1,1 +1,1 @@
│ -a
│ +b
○ Change qpvuntsmwlqt
+ qpvuntsm 2ac85fd1 (no description set)
- qpvuntsm hidden 6b1027d2 (no description set)
diff --git a/file b/file
index 7898192261..6178079822 100644
--- a/file
+++ b/file
@@ -1,1 +1,1 @@
-a
+b
"###);
// Abandon the working copy commit.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["abandon"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r###"
Abandoned commit mzvwutvl 9f4fb57f (empty) (no description set)
Working copy now at: yqosqzyt 33f321c4 (empty) (no description set)
Parent commit : qpvuntsm 2ac85fd1 (no description set)
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "show", "-p", "--git"]);
insta::assert_snapshot!(&stdout, @r###"
e13dc1c7a3b3 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07:00
abandon commit 9f4fb57fba25a7b47ce5980a5d9a4766778331e8
args: jj abandon
Changed commits:
○ Change yqosqzytrlsw
+ yqosqzyt 33f321c4 (empty) (no description set)
○ Change mzvwutvlkqwt
- mzvwutvl hidden 9f4fb57f (empty) (no description set)
"###);
op log: add --op-diff option to embed operation diffs This is basically "log -p" for "op log". The flag name has "op" because --diff and --patch mean a similar thing in this context. Since -p implies --op-diff, user can just do "op log -p" if he's okay with verbose op + content diffs. Note that --no-graph affects both "op log" and "op diff" parts. We might want to do some style changes later, such as inserting/deleting blank lines, highlighting headers, etc.
2024-09-03 08:58:46 +00:00
// Try again with "op log".
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log", "--git"]);
insta::assert_snapshot!(&stdout, @r#"
@ e13dc1c7a3b3 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07:00
│ abandon commit 9f4fb57fba25a7b47ce5980a5d9a4766778331e8
│ args: jj abandon
│
│ Changed commits:
│ ○ Change yqosqzytrlsw
│ + yqosqzyt 33f321c4 (empty) (no description set)
│ ○ Change mzvwutvlkqwt
│ - mzvwutvl hidden 9f4fb57f (empty) (no description set)
○ c53f5f1afbc6 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
│ squash commits into 6b1027d2770cd0a39c468e525e52bf8c47e1464a
│ args: jj squash
│
│ Changed commits:
│ ○ Change mzvwutvlkqwt
│ │ + mzvwutvl 9f4fb57f (empty) (no description set)
│ │ ○ Change rlvkpnrzqnoo
│ ├─╯ - rlvkpnrz hidden 1d7f8f94 (no description set)
│ │ diff --git a/file b/file
│ │ index 7898192261..6178079822 100644
│ │ --- a/file
│ │ +++ b/file
│ │ @@ -1,1 +1,1 @@
│ │ -a
│ │ +b
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 2ac85fd1 (no description set)
│ - qpvuntsm hidden 6b1027d2 (no description set)
│ diff --git a/file b/file
│ index 7898192261..6178079822 100644
│ --- a/file
│ +++ b/file
│ @@ -1,1 +1,1 @@
│ -a
│ +b
○ 874d3a8b4c77 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
│ snapshot working copy
│ args: jj squash
│
│ Changed commits:
│ ○ Change rlvkpnrzqnoo
│ + rlvkpnrz 1d7f8f94 (no description set)
│ - rlvkpnrz hidden 56950632 (empty) (no description set)
│ diff --git a/file b/file
│ index 7898192261..6178079822 100644
│ --- a/file
│ +++ b/file
│ @@ -1,1 +1,1 @@
│ -a
│ +b
○ 8f6a879bef11 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ new empty commit
│ args: jj new
│
│ Changed commits:
│ ○ Change rlvkpnrzqnoo
│ + rlvkpnrz 56950632 (empty) (no description set)
○ 6188e9d1f7da test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
│ snapshot working copy
│ args: jj new
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 6b1027d2 (no description set)
│ - qpvuntsm hidden 230dd059 (empty) (no description set)
│ diff --git a/file b/file
│ new file mode 100644
│ index 0000000000..7898192261
│ --- /dev/null
│ +++ b/file
│ @@ -1,0 +1,1 @@
│ +a
○ b51416386f26 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ add workspace 'default'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 230dd059 (empty) (no description set)
○ 9a7d829846af test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
│ initialize repo
│
│ Changed commits:
│ ○ Change zzzzzzzzzzzz
│ + zzzzzzzz 00000000 (empty) (no description set)
○ 000000000000 root()
"#);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
}
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
fn init_bare_git_repo(git_repo_path: &Path) -> git2::Repository {
let git_repo = git2::Repository::init_bare(git_repo_path).unwrap();
let git_blob_oid = git_repo.blob(b"some content").unwrap();
let mut git_tree_builder = git_repo.treebuilder(None).unwrap();
git_tree_builder
.insert("some-file", git_blob_oid, 0o100644)
.unwrap();
let git_tree_id = git_tree_builder.write().unwrap();
drop(git_tree_builder);
let git_tree = git_repo.find_tree(git_tree_id).unwrap();
let git_signature = git2::Signature::new(
"Git User",
"git.user@example.com",
&git2::Time::new(123, 60),
)
.unwrap();
git_repo
.commit(
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Some("refs/heads/bookmark-1"),
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
&git_signature,
&git_signature,
"Commit 1",
&git_tree,
&[],
)
.unwrap();
git_repo
.commit(
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Some("refs/heads/bookmark-2"),
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
&git_signature,
&git_signature,
"Commit 2",
&git_tree,
&[],
)
.unwrap();
git_repo
.commit(
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Some("refs/heads/bookmark-3"),
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
&git_signature,
&git_signature,
"Commit 3",
&git_tree,
&[],
)
.unwrap();
drop(git_tree);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
git_repo.set_head("refs/heads/bookmark-1").unwrap();
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
git_repo
}
fn modify_git_repo(git_repo: git2::Repository) -> git2::Repository {
let git_blob_oid = git_repo.blob(b"more content").unwrap();
let mut git_tree_builder = git_repo.treebuilder(None).unwrap();
git_tree_builder
.insert("next-file", git_blob_oid, 0o100644)
.unwrap();
let git_tree_id = git_tree_builder.write().unwrap();
drop(git_tree_builder);
let git_tree = git_repo.find_tree(git_tree_id).unwrap();
let git_signature = git2::Signature::new(
"Git User",
"git.user@example.com",
&git2::Time::new(123, 60),
)
.unwrap();
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
let bookmark1_commit = git_repo
.find_reference("refs/heads/bookmark-1")
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
.unwrap()
.peel_to_commit()
.unwrap();
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
let bookmark2_commit = git_repo
.find_reference("refs/heads/bookmark-2")
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
.unwrap()
.peel_to_commit()
.unwrap();
git_repo
.commit(
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Some("refs/heads/bookmark-1"),
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
&git_signature,
&git_signature,
"Commit 4",
&git_tree,
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
&[&bookmark1_commit],
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
)
.unwrap();
git_repo
.commit(
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
Some("refs/heads/bookmark-2"),
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
&git_signature,
&git_signature,
"Commit 5",
&git_tree,
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
&[&bookmark2_commit],
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
)
.unwrap();
git_repo
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
.find_reference("refs/heads/bookmark-3")
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
.unwrap()
.delete()
.unwrap();
drop(git_tree);
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
drop(bookmark1_commit);
drop(bookmark2_commit);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
git_repo
}
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path, op_id: &str) -> String {
Include @ in the default revset Yields a less confusing behavior of `jj log` after pushing a commit.
2022-10-19 05:21:25 +00:00
test_env.jj_cmd_success(
repo_path,
&["log", "-T", "commit_id", "--at-op", op_id, "-r", "all()"],
)
tests: add test for `jj op log` and `--at-op` We can't easily test much of the output of `jj op log` because it's unstable, but here are at least a few tests.
2022-04-23 18:34:40 +00:00
}
Reference in a new issue Copy permalink