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

2258 lines
88 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
);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
@ d009cfc04993 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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();
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, 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!(
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ d009cfc04993 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07: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
│ 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07: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
│ add workspace 'default'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 230dd059 (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
],
);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
Hint: Try specifying one of the operations by ID: fd29e648380b, 3e8ef7115a0c
"#);
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, \"┴\", \"┝\"))'",
),
],
);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
$ d009cfc04993 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
┝ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.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
│ add workspace 'default'
┴ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
}
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
templates: Add new template alias builtin_log_compact_full_description For a new user, it is not clear how to view the full commit message/description of a change with `jj log`. This fix this, add a new template alias `builtin_log_compact_full_description` to display the commit like `builtin_log_compact` does but with a full description. The user can set it to true on the config like this: ``` templates.log = builtin_log_compact_full_description ``` Fixes: #3688
2024-10-13 19:10:00 +00:00
- builtin_log_compact_full_description
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_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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stdout, @r#"
eac759b9ab75 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'
cli: give root operation special treatment in template (like root commit)
2024-01-14 01:02:15 +00:00
000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07: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
add workspace 'default'
Changed commits:
Change qpvuntsmwlqt
+ qpvuntsm 230dd059 (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""#,
],
);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_debug_snapshot!(stdout, @r#""ef17\0f412\0eac7\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]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(render(r#"id ++ "\n""#), @r#"
@ eac759b9ab75793fd3da96e60939fb48f2cd2b2a9c1f13ffe723cf620f3005b8d3e7e923634a07ea39513e4f2f360c87b9ad5d331cf90d7a844864b83b72eba1
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
○ 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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,
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
time.start(), time.end(), time.duration()) ++ "\n""#), @r#"
@ eac75 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
○ 00000 false @ 1970-01-01 00:00:00.000 +00:00 1970-01-01 00:00:00.000 +00:00 less than a microsecond
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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.
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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>|
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
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]
operation templates: use end time instead of start time See also inline comment. For a second, I thought about replacing the word "lasted" with "after" to make it clearer, but I think it's not necessary.
2024-10-13 02:02:44 +00:00
'format_time_range(time_range)' = 'time_range.end().ago() ++ ", lasted " ++ time_range.duration()'
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
"#,
);
let regex = Regex::new(r"\d\d years").unwrap();
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(regex.replace_all(&stdout, "NN years"), @r#"
@ eac759b9ab75 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
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(render(r#"builtin_op_log_compact"#), @r#"
d009cfc04993 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
templates: add missing "\n" to builtin "root" output
2024-03-13 13:36:03 +00:00
add workspace 'default'
000000000000 root()
[EOF]
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(render(r#"builtin_op_log_comfortable"#), @r#"
d009cfc04993 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
templates: add missing "\n" to builtin "root" output
2024-03-13 13:36:03 +00:00
add workspace 'default'
000000000000 root()
[EOF]
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
}
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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ b7cd3d0069f6 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07: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
│ snapshot working copy
│ args: jj debug snapshot
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
○ 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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ b7cd3d0069f6
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
│ 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75
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
○ 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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ b7cd3d0069f6
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
│ 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75
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
│ 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)
○ 000000000000 root()
"#);
// Nested diff stat shouldn't exceed the terminal width
insta::assert_snapshot!(render(&["op", "log", "-n1", "--stat"], 40, true), @r#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ b7cd3d0069f6
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
│ 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#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
b7cd3d0069f6
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
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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["op", "log"]), @r#"
@ 116edde65ded 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ bee8c02a64bf 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00: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
// Abandon old operations. The working-copy operation id should be updated.
let (_stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "abandon", "..@-"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stderr, @r#"
Abandoned 2 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("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!(
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r#"
Current operation: OperationId("b0711a8ac91f5ac088cff9b57c9daf29dc61b1b4fedcbb9a07fe4c7f7da1e60e333c787eacf73d1e0544db048a4fe9c6c089991b4a67e25365c4f411fa8b489f")
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")))
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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!(
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
test_env.jj_cmd_success(&repo_path, &["op", "log", "-n1", "--ignore-working-copy"]), @r#"
@ 0508a30825ed test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.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 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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
// 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", "@-"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stderr, @r#"
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
Abandoned 1 operations and reparented 1 descendant operations.
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
Warning: The working copy operation b0711a8ac91f is not updated because it differs from the repo 0508a30825ed.
"#);
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!(
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
test_env.jj_cmd_success(&repo_path, &["debug", "local-working-copy", "--ignore-working-copy"]), @r#"
Current operation: OperationId("b0711a8ac91f5ac088cff9b57c9daf29dc61b1b4fedcbb9a07fe4c7f7da1e60e333c787eacf73d1e0544db048a4fe9c6c089991b4a67e25365c4f411fa8b489f")
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")))
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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!(
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
test_env.jj_cmd_success(&repo_path, &["op", "log", "-n1", "--ignore-working-copy"]), @r#"
@ 2631d5576876 test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.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 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'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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
}
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();
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(head_op_id, @"b0711a8ac91f");
insta::assert_snapshot!(prev_op_id, @"116edde65ded");
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
// 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", "@-"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
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: The "@" expression resolved to more than one operation
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
Hint: Try specifying one of the operations by ID: b0711a8ac91f, 617923db9f7a
"#);
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 (_, other_head_op_id) = stderr.trim_end().rsplit_once(", ").unwrap();
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(other_head_op_id, @"617923db9f7a");
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
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]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stderr, @r#"
Error: Cannot abandon the current operation b0711a8ac91f
"#);
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
// Can't abandon the other head operation.
let stderr = test_env.jj_cmd_failure(&repo_path, &["op", "abandon", other_head_op_id]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stderr, @r#"
Error: Cannot abandon the current operation 617923db9f7a
"#);
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
// 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stdout, @r#"
@ 7e65e7e27e34 test-username@host.example.com 2001-02-03 04:05:17.000 +07:00 - 2001-02-03 04:05:17.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: 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ 0508a30825ed test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
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
│ │ commit 220cb0b1b5d1c03cc0d351139d824598bb3c1967
│ │ args: jj commit -m 'commit 3'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
│ ○ 617923db9f7a test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00
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
├─╯ commit 81a4ef3dd421f3184289df1c58bd3a16ea1e3d8e
│ args: jj commit '--at-op=@--' -m 'commit 4'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ bee8c02a64bf test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
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
│ commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj commit -m 'commit 1'
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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
#[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();
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(head_op_id, @"f999e12a5d8b");
insta::assert_snapshot!(bad_op_id, @"e7377e6a642b");
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
// 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(strip_last_line(&stderr), @r#"
Internal error: Failed to index commits at operation e7377e6a642bae88039615ee159117d49688719e9d5ece9de8b0b42d7be7076904d2fa8381391f8289a0c3527405de81e8dd6504655311c69175c3681786dd3c
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
Caused by:
1: Object ddf84fc5e0dd314092b3dfb13e09e37fa7d04ef9 of type commit not found
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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
// "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],
);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stdout, @r#"
@ f999e12a5d8b test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07:00
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
│ describe commit 37bb762e5dc08073ec4323bdffc023a0f0cc901e
│ args: jj describe -m4
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ fb75e6b1c70a test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
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
│ new empty commit
│ args: jj new -m3
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 44d11f83204d test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07:00
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
│ abandon commit ddf84fc5e0dd314092b3dfb13e09e37fa7d04ef9
│ args: jj abandon
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ e7377e6a642b test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07:00
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
│ describe commit 8b64ddff700dc214dec05d915e85ac692233e6e3
│ args: jj describe -m2
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 319610522e90 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07:00
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
│ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
│ args: jj describe -m1
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07:00
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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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!(stderr, @"");
// "op abandon" should work.
let (_stdout, stderr) =
test_env.jj_cmd_ok(&repo_path, &["op", "abandon", &format!("..{bad_op_id}")]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(stderr, @r#"
Abandoned 3 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"]);
templater: make "git_head" return boolean, render it as "git_head()" For the same reason as the root revision is indicated by "root()".
2024-10-13 10:57:52 +00:00
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
templater: make "git_head" return boolean, render it as "git_head()" For the same reason as the root revision is indicated by "root()".
2024-10-13 10:57:52 +00:00
○ zsuskuln test.user@example.com 2001-02-03 08:05:10 git_head() f652c321
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
│ (empty) (no description set)
◆ zzzzzzzz root() 00000000
templater: make "git_head" return boolean, render it as "git_head()" For the same reason as the root revision is indicated by "root()".
2024-10-13 10:57:52 +00:00
"#);
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
}
templates: Demo bug where operation summary is printed w/o color in `jj undo`
2024-10-07 03:00:49 +00:00
#[test]
fn test_op_summary_diff_template() {
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");
// Tests in color (easier to read with `less -R`)
test_env.jj_cmd_ok(&repo_path, &["new", "--no-edit", "-m=scratch"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "undo", "--color=always"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
Undid operation: ac20a4ff4791 (2001-02-03 08:05:08) new empty commit
templates: Demo bug where operation summary is printed w/o color in `jj undo`
2024-10-07 03:00:49 +00:00
"#);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"diff",
"--from",
"0000000",
"--to",
"@",
"--color=always",
],
);
insta::assert_snapshot!(&stdout, @r#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 000000000000 root()
To operation: e3792fce5b1f (2001-02-03 08:05:09) undo operation ac20a4ff47914da9a2e43677b94455b86383bfb9227374d6531ecee85b9ff9230eeb96416a24bb27e7477aa18d50c01810e97c6a008b5c584224650846f4c05b
templates: Demo bug where operation summary is printed w/o color in `jj undo`
2024-10-07 03:00:49 +00:00
Changed commits:
○ Change qpvuntsmwlqt
+ qpvuntsm 230dd059 (empty) (no description set)
"#);
// Tests with templates
test_env.jj_cmd_ok(&repo_path, &["new", "--no-edit", "-m=scratch"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["op", "undo", "--color=debug"]);
insta::assert_snapshot!(&stdout, @"");
insta::assert_snapshot!(&stderr, @r#"
formatter & colors.toml: replace `op_log` color label with `operation` Cleans up after 7051effa8f It's split into "op_log operation" and just "operation" for the summaries (as suggested by Yuya). The color labels use "operation".
2024-10-14 17:48:51 +00:00
Undid operation: <<operation id short::2301f6e6ec31>><<operation:: (>><<operation time end local format::2001-02-03 08:05:11>><<operation::) >><<operation description first_line::new empty commit>>
templates: Demo bug where operation summary is printed w/o color in `jj undo`
2024-10-07 03:00:49 +00:00
"#);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"op",
"diff",
"--from",
"0000000",
"--to",
"@",
"--color=debug",
],
);
insta::assert_snapshot!(&stdout, @r#"
formatter & colors.toml: replace `op_log` color label with `operation` Cleans up after 7051effa8f It's split into "op_log operation" and just "operation" for the summaries (as suggested by Yuya). The color labels use "operation".
2024-10-14 17:48:51 +00:00
From operation: <<operation id short::000000000000>><<operation:: >><<operation root::root()>>
To operation: <<operation id short::d208ae1b4e3c>><<operation:: (>><<operation time end local format::2001-02-03 08:05:12>><<operation::) >><<operation description first_line::undo operation 2301f6e6ec31931a9b0a594742d6035a44c05250d1707f7f8678e888b11a98773ef07bf0e8008a5bccddf7114da4a35d1a1b1f7efa37c1e6c80d6bdb8f0d7a90>>
templates: Demo bug where operation summary is printed w/o color in `jj undo`
2024-10-07 03:00:49 +00:00
Changed commits:
○ Change qpvuntsmwlqt
<<diff added::+>> <<change_id shortest prefix::q>><<change_id shortest rest::pvuntsm>> <<commit_id shortest prefix::2>><<commit_id shortest rest::30dd059>> <<empty::(empty)>> <<empty description placeholder::(no description set)>>
"#);
}
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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
@ 4d05b146ac44 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 85a54acdbc88 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
// 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 000000000000 root()
To operation: 000000000000 root()
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", "--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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 4d05b146ac44 (2001-02-03 08:05:07) check out git remote's default branch
To operation: 4d05b146ac44 (2001-02-03 08:05:07) check out git remote's default branch
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
// 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 85a54acdbc88 (2001-02-03 08:05:07) fetch from git remote into empty repo
To operation: 4d05b146ac44 (2001-02-03 08:05:07) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 000000000000 root()
To operation: 4d05b146ac44 (2001-02-03 08:05:07) 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
+ ulyvmwyz 1d843d1f bookmark-1 | Commit 1
○ Change tqyxmsztkvot
+ tqyxmszt 3e785984 bookmark-3@origin | Commit 3
○ Change yuvsmzqkmpws
+ yuvsmzqk 3d9189bc 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 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 4d05b146ac44 (2001-02-03 08:05:07) 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
- ulyvmwyz hidden 1d843d1f Commit 1
○ Change tqyxmsztkvot
- tqyxmszt hidden 3e785984 Commit 3
○ Change yuvsmzqkmpws
- yuvsmzqk hidden 3d9189bc 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
@ cd3fc3ddbdd9 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ 4d05b146ac44 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
│ ○ 484785c371e5 test-username@host.example.com 2001-02-03 04:05:15.000 +07:00 - 2001-02-03 04:05:15.000 +07: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
├─╯ point bookmark bookmark-1 to commit 3d9189bc56a1972729350456eb95ec5bf90be2a8
│ args: jj bookmark set bookmark-1 -r bookmark-2@origin --at-op @-
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 85a54acdbc88 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation diff` command
2024-05-02 08:29:31 +00:00
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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 4d05b146ac44 (2001-02-03 08:05:07) check out git remote's default branch
To operation: cd3fc3ddbdd9 (2001-02-03 08:05:16) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 484785c371e5 (2001-02-03 08:05:15) point bookmark bookmark-1 to commit 3d9189bc56a1972729350456eb95ec5bf90be2a8
To operation: cd3fc3ddbdd9 (2001-02-03 08:05:16) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: cd3fc3ddbdd9 (2001-02-03 08:05:16) reconcile divergent operations
To operation: 894f1f54aabe (2001-02-03 08:05:20) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 894f1f54aabe (2001-02-03 08:05:20) fetch from git remote(s) origin
To operation: ed134e3dc5c6 (2001-02-03 08:05:22) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: ed134e3dc5c6 (2001-02-03 08:05:22) create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
To operation: 871bda1a359f (2001-02-03 08:05:24) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: ed134e3dc5c6 (2001-02-03 08:05:22) create bookmark bookmark-2 pointing to commit d487febd08e690ee775a4e0387e30d544307e409
To operation: 871bda1a359f (2001-02-03 08:05:24) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 871bda1a359f (2001-02-03 08:05:24) track remote bookmark bookmark-2@origin
To operation: 2604b8b3b9e5 (2001-02-03 08:05:28) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 2604b8b3b9e5 (2001-02-03 08:05:28) new empty commit
To operation: e64617a51cdb (2001-02-03 08:05:30) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: e64617a51cdb (2001-02-03 08:05:30) point bookmark bookmark-1 to commit 358b82d6be53fa9b062325abb8bc820a8b34c68d
To operation: e07e94fbdd09 (2001-02-03 08:05:32) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: e07e94fbdd09 (2001-02-03 08:05:32) delete bookmark bookmark-2
To operation: 203fe2a7ed9e (2001-02-03 08:05:34) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: eac759b9ab75 (2001-02-03 08:05:07) add workspace 'default'
To operation: 187a5a9d8a22 (2001-02-03 08:05:08) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 187a5a9d8a22 (2001-02-03 08:05:08) snapshot working copy
To operation: a7e535e73c4b (2001-02-03 08:05:08) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 15c3c5d0baf0 (2001-02-03 08:05:11) snapshot working copy
To operation: 894c12d90345 (2001-02-03 08:05:11) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 894c12d90345 (2001-02-03 08:05:11) squash commits into 6b1027d2770cd0a39c468e525e52bf8c47e1464a
To operation: e5505aa79d31 (2001-02-03 08:05:13) 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();
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(base_op_id, @"eac759b9ab75");
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
// 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
@ 779ecb7ea7f0 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07: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
├─╮ reconcile divergent operations
│ │ args: jj op log
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ d700dc16fded test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07: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
│ │ new empty commit
│ │ args: jj new 'all:@-+' -mA
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ b47de32023e1 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07: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
│ │ snapshot working copy
│ │ args: jj new 'all:@-+' -mA
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ 8a31868f615d test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07: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
│ │ new empty commit
│ │ args: jj new 'root()' -mA.2
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ 2cd33ddecde8 test-username@host.example.com 2001-02-03 04:05:10.000 +07:00 - 2001-02-03 04:05:10.000 +07: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
│ │ snapshot working copy
│ │ args: jj new 'root()' -mA.2
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ │ d86c1ae55c48 test-username@host.example.com 2001-02-03 04:05:09.000 +07:00 - 2001-02-03 04:05:09.000 +07: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
│ │ new empty commit
│ │ args: jj new 'root()' -mA.1
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
│ ○ 13b143e1f4f9 test-username@host.example.com 2001-02-03 04:05:12.000 +07:00 - 2001-02-03 04:05:12.000 +07: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
├─╯ describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
│ args: jj describe --at-op eac759b9ab75 -mB
○ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07: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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
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();
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(head_op_id, @"779ecb7ea7f0");
insta::assert_snapshot!(p1_op_id, @"d700dc16fded");
insta::assert_snapshot!(p2_op_id, @"13b143e1f4f9");
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
// 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: d700dc16fded (2001-02-03 08:05:11) new empty commit
To operation: 13b143e1f4f9 (2001-02-03 08:05:12) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: 13b143e1f4f9 (2001-02-03 08:05:12) describe commit 230dd059e1b059aefc0da06a2e5a7dbf22362f22
To operation: d700dc16fded (2001-02-03 08:05:11) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: eac759b9ab75 (2001-02-03 08:05:07) add workspace 'default'
To operation: f3052392e08c (2001-02-03 08:05:08) 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#"
templates: make `op_summary` more readable Added colons to make it seem less like an English sentence, see https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776 I believe printing both the start and end times is excessive for a summary. For now, I have it print just the start time for consistency. I intend to change it to print the ending time later. I was a bit torn on whether to use `format_timestamp(self.time().start())` or `self.time().start().ago()`. The latter looks better, but is less configurable and worse for dates long ago. In the future, we could add a `format_op_summary_timestamp` function and/or a template function that uses `.ago()` for recent dates and absolute dates for old dates.
2024-10-07 03:00:49 +00:00
From operation: eac759b9ab75 (2001-02-03 08:05:07) add workspace 'default'
To operation: f3052392e08c (2001-02-03 08:05:08) 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
@ 4d05b146ac44 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 85a54acdbc88 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 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
│ add workspace 'default'
○ 000000000000 root()
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
// 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", "@"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
4d05b146ac44 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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", "@-"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
85a54acdbc88 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
140254f5a707 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
4d5647c16e09 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
c23f32312992 test-username@host.example.com 2001-02-03 04:05:18.000 +07:00 - 2001-02-03 04:05:18.000 +07: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 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
eb6a6c523f67 test-username@host.example.com 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07: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
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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
eb6a6c523f67 test-username@host.example.com 2001-02-03 04:05:20.000 +07:00 - 2001-02-03 04:05:20.000 +07: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
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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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: 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
0228d6c4044a 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
f37c3d23beab test-username@host.example.com 2001-02-03 04:05:26.000 +07:00 - 2001-02-03 04:05:26.000 +07: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
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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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 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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
ee9e64b76138 test-username@host.example.com 2001-02-03 04:05:28.000 +07:00 - 2001-02-03 04:05:28.000 +07: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
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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
cd1704964f59 test-username@host.example.com 2001-02-03 04:05:30.000 +07:00 - 2001-02-03 04:05:30.000 +07: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
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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` command
2024-05-02 08:29:31 +00:00
}
#[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"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
187a5a9d8a22 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 `jj operation show` command
2024-05-02 08:29:31 +00: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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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", "@", "-p", "--git"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
a7e535e73c4b 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 `jj operation show` command
2024-05-02 08:29:31 +00:00
new empty commit
args: jj new
Changed commits:
○ Change rlvkpnrzqnoo
+ rlvkpnrz 56950632 (empty) (no description set)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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", "show", "-p", "--git"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
894c12d90345 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00: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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
"#);
cli: add `jj operation show` 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", "show", "-p", "--git"]);
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
insta::assert_snapshot!(&stdout, @r#"
e5505aa79d31 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07:00
cli: add `jj operation show` command
2024-05-02 08:29:31 +00: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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +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
// Try again with "op log".
let stdout = test_env.jj_cmd_success(&repo_path, &["op", "log", "--git"]);
insta::assert_snapshot!(&stdout, @r#"
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
@ e5505aa79d31 test-username@host.example.com 2001-02-03 04:05:13.000 +07:00 - 2001-02-03 04:05:13.000 +07: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
│ 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)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 894c12d90345 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07: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
│ 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 15c3c5d0baf0 test-username@host.example.com 2001-02-03 04:05:11.000 +07:00 - 2001-02-03 04:05:11.000 +07: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
│ 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ a7e535e73c4b test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07: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
│ new empty commit
│ args: jj new
│
│ Changed commits:
│ ○ Change rlvkpnrzqnoo
│ + rlvkpnrz 56950632 (empty) (no description set)
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ 187a5a9d8a22 test-username@host.example.com 2001-02-03 04:05:08.000 +07:00 - 2001-02-03 04:05:08.000 +07: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
│ 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
repo: teach OpStore about the root commit id This removes an invalid View state from the root operation. Note that the root index will have to be reindexed in order to resolve "root()" in the root operation. I don't think this would practically matter, so this patch doesn't bump the index version to invalidate the existing indexes. See also 48a9f9ef56c1 "repo: use Transaction for creating repo-init operation."
2024-10-07 02:00:37 +00:00
○ eac759b9ab75 test-username@host.example.com 2001-02-03 04:05:07.000 +07:00 - 2001-02-03 04:05:07.000 +07: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
│ add workspace 'default'
│
│ Changed commits:
│ ○ Change qpvuntsmwlqt
│ + qpvuntsm 230dd059 (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