2022-11-26 23:57:50 +00:00
|
|
|
// Copyright 2022 The Jujutsu Authors
|
2022-03-26 21:02:04 +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.
|
|
|
|
|
2022-08-31 04:35:56 +00:00
|
|
|
use std::path::Path;
|
|
|
|
|
2022-04-15 05:48:40 +00:00
|
|
|
use crate::common::TestEnvironment;
|
2022-03-30 17:47:11 +00:00
|
|
|
|
2022-03-26 21:02:04 +00:00
|
|
|
#[test]
|
2022-05-21 13:38:56 +00:00
|
|
|
fn test_new() {
|
2022-03-26 21:02:04 +00:00
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2022-03-26 21:02:04 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "add a file"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "-m", "a new commit"]);
|
2022-03-26 21:02:04 +00:00
|
|
|
|
2022-08-31 04:35:56 +00:00
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 4f2d6e0a3482a6a34e4856a4a63869c0df109e79 a new commit
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 5d5c60b2aa96b8dbf55710656c50285c66cdcd74 add a file
|
|
|
|
◉ 0000000000000000000000000000000000000000
|
2022-03-26 21:02:04 +00:00
|
|
|
"###);
|
2022-05-21 13:38:56 +00:00
|
|
|
|
|
|
|
// Start a new change off of a specific commit (the root commit in this case).
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "-m", "off of root", "root()"]);
|
2022-08-31 04:35:56 +00:00
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 026537ddb96b801b9cb909985d5443aab44616c1 off of root
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ 4f2d6e0a3482a6a34e4856a4a63869c0df109e79 a new commit
|
|
|
|
│ ◉ 5d5c60b2aa96b8dbf55710656c50285c66cdcd74 add a file
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0000000000000000000000000000000000000000
|
2022-05-21 13:38:56 +00:00
|
|
|
"###);
|
2023-11-20 20:39:16 +00:00
|
|
|
|
|
|
|
// --edit is a no-op
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--edit", "-m", "yet another commit"]);
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
|
|
|
@ 101cbec5cae8049cb9850a906ef3675631ed48fa yet another commit
|
|
|
|
◉ 026537ddb96b801b9cb909985d5443aab44616c1 off of root
|
|
|
|
│ ◉ 4f2d6e0a3482a6a34e4856a4a63869c0df109e79 a new commit
|
|
|
|
│ ◉ 5d5c60b2aa96b8dbf55710656c50285c66cdcd74 add a file
|
|
|
|
├─╯
|
|
|
|
◉ 0000000000000000000000000000000000000000
|
|
|
|
"###);
|
|
|
|
|
|
|
|
// --edit cannot be used with --no-edit
|
|
|
|
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["new", "--edit", "B", "--no-edit", "D"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
error: the argument '--edit' cannot be used with '--no-edit'
|
|
|
|
|
|
|
|
Usage: jj new <REVISIONS>...
|
|
|
|
|
|
|
|
For more information, try '--help'.
|
|
|
|
"###);
|
2022-03-26 21:02:04 +00:00
|
|
|
}
|
2022-08-31 04:35:56 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_merge() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2022-08-31 04:35:56 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["branch", "create", "main"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "add file1"]);
|
2022-08-31 04:35:56 +00:00
|
|
|
std::fs::write(repo_path.join("file1"), "a").unwrap();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "root()", "-m", "add file2"]);
|
2022-08-31 04:35:56 +00:00
|
|
|
std::fs::write(repo_path.join("file2"), "b").unwrap();
|
|
|
|
|
|
|
|
// Create a merge commit
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "main", "@"]);
|
2022-08-31 04:35:56 +00:00
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 0c4e5b9b68ae0cbe7ce3c61042619513d09005bf
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ f399209d9dda06e8a25a0c8e9a0cde9f421ff35d add file2
|
|
|
|
◉ │ 38e8e2f6c92ffb954961fc391b515ff551b41636 add file1
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0000000000000000000000000000000000000000
|
2022-08-31 04:35:56 +00:00
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["print", "file1"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"a");
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["print", "file2"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"b");
|
2022-08-31 05:31:18 +00:00
|
|
|
|
2023-11-20 20:39:16 +00:00
|
|
|
// Same test with `--no-edit`
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["new", "main", "@", "--no-edit"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
2023-11-20 22:25:40 +00:00
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Created new commit znkkpsqq 200ed1a1 (empty) (no description set)
|
|
|
|
"###);
|
2023-11-20 20:39:16 +00:00
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
|
|
|
◉ 200ed1a14c8acf09783dafefe5bebf2ff58f12fd
|
|
|
|
├─╮
|
|
|
|
│ @ f399209d9dda06e8a25a0c8e9a0cde9f421ff35d add file2
|
|
|
|
◉ │ 38e8e2f6c92ffb954961fc391b515ff551b41636 add file1
|
|
|
|
├─╯
|
|
|
|
◉ 0000000000000000000000000000000000000000
|
|
|
|
"###);
|
|
|
|
|
2022-08-31 05:31:18 +00:00
|
|
|
// Same test with `jj merge`
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["merge", "main", "@"]);
|
2022-08-31 05:31:18 +00:00
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-11-20 20:39:16 +00:00
|
|
|
@ 3a44e52b073cbb5deb11bb8fa0763a369e96427a
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ f399209d9dda06e8a25a0c8e9a0cde9f421ff35d add file2
|
|
|
|
◉ │ 38e8e2f6c92ffb954961fc391b515ff551b41636 add file1
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0000000000000000000000000000000000000000
|
2022-08-31 05:31:18 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
// `jj merge` with less than two arguments is an error
|
2022-11-18 20:50:39 +00:00
|
|
|
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["merge"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-01-17 23:35:34 +00:00
|
|
|
warning: `jj merge` is deprecated; use `jj new` instead, which is equivalent
|
|
|
|
warning: `jj merge` will be removed in a future version, and this will be a hard error
|
2022-11-18 20:50:39 +00:00
|
|
|
Error: Merge requires at least two revisions
|
|
|
|
"###);
|
|
|
|
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["merge", "main"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-01-17 23:35:34 +00:00
|
|
|
warning: `jj merge` is deprecated; use `jj new` instead, which is equivalent
|
|
|
|
warning: `jj merge` will be removed in a future version, and this will be a hard error
|
2022-11-18 20:50:39 +00:00
|
|
|
Error: Merge requires at least two revisions
|
|
|
|
"###);
|
2022-08-31 07:41:08 +00:00
|
|
|
|
|
|
|
// merge with non-unique revisions
|
2023-11-20 20:39:16 +00:00
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "@", "3a44e"]);
|
2022-08-31 07:41:08 +00:00
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-11-20 20:39:16 +00:00
|
|
|
Error: More than one revset resolved to revision 3a44e52b073c
|
2022-08-31 07:41:08 +00:00
|
|
|
"###);
|
2022-08-31 08:56:37 +00:00
|
|
|
|
|
|
|
// merge with root
|
2023-09-03 03:47:23 +00:00
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "@", "root()"]);
|
2022-11-18 20:50:39 +00:00
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Error: Cannot merge with root revision
|
|
|
|
"###);
|
2022-08-31 04:35:56 +00:00
|
|
|
}
|
|
|
|
|
2023-02-04 20:42:03 +00:00
|
|
|
#[test]
|
|
|
|
fn test_new_insert_after() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-02-04 20:42:03 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
|
2023-11-20 20:34:14 +00:00
|
|
|
// --insert-after can be repeated (this does not affect the outcome); --after is
|
|
|
|
// an alias
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(
|
|
|
|
&repo_path,
|
|
|
|
&[
|
|
|
|
"new",
|
|
|
|
"--insert-after",
|
|
|
|
"-m",
|
|
|
|
"G",
|
|
|
|
"--after",
|
|
|
|
"B",
|
|
|
|
"--after",
|
|
|
|
"D",
|
|
|
|
],
|
|
|
|
);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-02-04 20:42:03 +00:00
|
|
|
Rebased 2 descendant commits
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: kxryzmor ca7c6481 (empty) G
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : kkmpptxz 6041917c B | (empty) B
|
|
|
|
Parent commit : vruxwmqv c9257eff D | (empty) D
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ C
|
|
|
|
│ ◉ F
|
2023-02-09 02:53:47 +00:00
|
|
|
╭─┤
|
|
|
|
@ │ G
|
|
|
|
├───╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ │ ◉ D
|
|
|
|
◉ │ │ B
|
|
|
|
◉ │ │ A
|
|
|
|
├───╯
|
|
|
|
│ ◉ E
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--insert-after", "-m", "H", "D"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-02-04 20:42:03 +00:00
|
|
|
Rebased 3 descendant commits
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: uyznsvlq fcf8281b (empty) H
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : vruxwmqv c9257eff D | (empty) D
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ C
|
|
|
|
│ ◉ F
|
2023-02-09 02:53:47 +00:00
|
|
|
╭─┤
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ G
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ │ @ H
|
|
|
|
│ │ ◉ D
|
|
|
|
◉ │ │ B
|
|
|
|
◉ │ │ A
|
|
|
|
├───╯
|
|
|
|
│ ◉ E
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
2023-11-20 20:34:14 +00:00
|
|
|
|
|
|
|
// --after cannot be used with --before
|
|
|
|
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["new", "--after", "B", "--before", "D"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
error: the argument '--insert-after' cannot be used with '--insert-before'
|
|
|
|
|
|
|
|
Usage: jj new --insert-after <REVISIONS>...
|
|
|
|
|
|
|
|
For more information, try '--help'.
|
|
|
|
"###);
|
2023-02-04 20:42:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_insert_after_children() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-02-04 20:42:03 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
// Check that inserting G after A and C doesn't try to rebase B (which is
|
|
|
|
// initially a child of A) onto G as that would create a cycle since B is
|
|
|
|
// a parent of C which is a parent G.
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--insert-after", "-m", "G", "A", "C"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: kxryzmor b48d4d73 (empty) G
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : qpvuntsm 65b1ef43 A | (empty) A
|
|
|
|
Parent commit : mzvwutvl ec18c57d C | (empty) C
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ G
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
├─╯
|
|
|
|
◉ A
|
|
|
|
│ ◉ F
|
|
|
|
│ ├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ │ ◉ E
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ D
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-02-04 20:42:03 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
2023-01-31 19:01:44 +00:00
|
|
|
#[test]
|
|
|
|
fn test_new_insert_before() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--insert-before", "-m", "G", "C", "F"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-01-31 19:01:44 +00:00
|
|
|
Rebased 2 descendant commits
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: kxryzmor ff6bbbc7 (empty) G
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : znkkpsqq 41a89ffc E | (empty) E
|
|
|
|
Parent commit : vruxwmqv c9257eff D | (empty) D
|
|
|
|
Parent commit : kkmpptxz 6041917c B | (empty) B
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ F
|
|
|
|
│ ◉ C
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
|
|
|
@ G
|
|
|
|
├─┬─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ ◉ B
|
|
|
|
│ │ ◉ A
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ │ D
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ├─╯
|
|
|
|
◉ │ E
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_insert_before_root_successors() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--insert-before", "-m", "G", "A", "D"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-01-31 19:01:44 +00:00
|
|
|
Rebased 5 descendant commits
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: kxryzmor 36541977 (empty) G
|
|
|
|
Parent commit : zzzzzzzz 00000000 (empty) (no description set)
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ F
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-03-15 03:37:56 +00:00
|
|
|
│ │ ◉ C
|
|
|
|
│ │ ◉ B
|
|
|
|
│ │ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
|
|
|
@ │ G
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_insert_before_no_loop() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
2023-02-28 11:30:57 +00:00
|
|
|
let template = r#"commit_id.short() ++ " " ++ if(description, description, "root")"#;
|
2023-02-28 10:43:14 +00:00
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", template]);
|
2023-01-31 19:01:44 +00:00
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 7705d353bf5d F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ 41a89ffcbba2 E
|
|
|
|
◉ │ c9257eff5bf9 D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ ec18c57d72d8 C
|
|
|
|
│ ◉ 6041917ceeb5 B
|
|
|
|
│ ◉ 65b1ef43c737 A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000 root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
let stderr =
|
|
|
|
test_env.jj_cmd_failure(&repo_path, &["new", "--insert-before", "-m", "G", "A", "C"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Error: Refusing to create a loop: commit 6041917ceeb5 would be both an ancestor and a descendant of the new commit
|
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_insert_before_no_root_merge() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "--insert-before", "-m", "G", "B", "D"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-01-31 19:01:44 +00:00
|
|
|
Rebased 4 descendant commits
|
2023-07-11 01:46:38 +00:00
|
|
|
Working copy now at: kxryzmor bf9fc493 (empty) G
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : qpvuntsm 65b1ef43 A | (empty) A
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ F
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-03-15 03:37:56 +00:00
|
|
|
│ │ ◉ C
|
|
|
|
│ │ ◉ B
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
|
|
|
@ │ G
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_insert_before_root() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
setup_before_insertion(&test_env, &repo_path);
|
|
|
|
insta::assert_snapshot!(get_short_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ F
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ E
|
|
|
|
◉ │ D
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ C
|
|
|
|
│ ◉ B
|
|
|
|
│ ◉ A
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ root
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
let stderr =
|
2023-09-03 03:47:23 +00:00
|
|
|
test_env.jj_cmd_failure(&repo_path, &["new", "--insert-before", "-m", "G", "root()"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-10-29 03:36:57 +00:00
|
|
|
Error: The root commit 000000000000 is immutable
|
2023-01-31 19:01:44 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
2024-01-19 00:29:56 +00:00
|
|
|
#[test]
|
|
|
|
fn test_new_conflicting_branches() {
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "one"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new", "-m", "two", "@-"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["branch", "create", "foo"]);
|
|
|
|
test_env.jj_cmd_ok(
|
|
|
|
&repo_path,
|
|
|
|
&[
|
|
|
|
"--at-op=@-",
|
|
|
|
"branch",
|
|
|
|
"create",
|
|
|
|
"foo",
|
|
|
|
"-r",
|
|
|
|
r#"description("one")"#,
|
|
|
|
],
|
|
|
|
);
|
|
|
|
|
|
|
|
// Trigger resolution of concurrent operations
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["st"]);
|
|
|
|
|
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "foo"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Error: Revset "foo" resolved to more than one revision
|
|
|
|
Hint: Branch foo resolved to multiple revisions because it's conflicted.
|
|
|
|
It resolved to these revisions:
|
|
|
|
kkmpptxz 66c6502d foo?? | (empty) two
|
|
|
|
qpvuntsm a9330854 foo?? | (empty) one
|
|
|
|
Set which revision the branch points to with `jj branch set foo -r <REVISION>`.
|
|
|
|
Prefix the expression with 'all' to allow any number of revisions (i.e. 'all:foo').
|
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_new_conflicting_change_ids() {
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["describe", "-m", "one"]);
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["--at-op=@-", "describe", "-m", "two"]);
|
|
|
|
|
|
|
|
// Trigger resolution of concurrent operations
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["st"]);
|
|
|
|
|
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "qpvuntsm"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Error: Revset "qpvuntsm" resolved to more than one revision
|
|
|
|
Hint: The revset "qpvuntsm" resolved to these revisions:
|
|
|
|
qpvuntsm?? d2ae6806 (empty) two
|
|
|
|
qpvuntsm?? a9330854 (empty) one
|
|
|
|
Some of these commits have the same change id. Abandon one of them with `jj abandon -r <REVISION>`.
|
|
|
|
Prefix the expression with 'all' to allow any number of revisions (i.e. 'all:qpvuntsm').
|
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
2023-01-31 19:01:44 +00:00
|
|
|
fn setup_before_insertion(test_env: &TestEnvironment, repo_path: &Path) {
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "A"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["commit", "-m", "A"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "B"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["commit", "-m", "B"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "C"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["describe", "-m", "C"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["new", "-m", "D", "root()"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "D"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["new", "-m", "E", "root()"]);
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "E"]);
|
2023-11-20 20:34:14 +00:00
|
|
|
// Any number of -r's is ignored
|
|
|
|
test_env.jj_cmd_ok(repo_path, &["new", "-m", "F", "-r", "D", "-r", "E"]);
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", "F"]);
|
2023-01-31 19:01:44 +00:00
|
|
|
}
|
|
|
|
|
2022-08-31 04:35:56 +00:00
|
|
|
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
2023-02-28 11:30:57 +00:00
|
|
|
let template = r#"commit_id ++ " " ++ description"#;
|
2023-02-28 10:43:14 +00:00
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", template])
|
2022-08-31 04:35:56 +00:00
|
|
|
}
|
2023-01-31 19:01:44 +00:00
|
|
|
|
|
|
|
fn get_short_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
2023-02-28 10:43:14 +00:00
|
|
|
let template = r#"if(description, description, "root")"#;
|
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", template])
|
2023-01-31 19:01:44 +00:00
|
|
|
}
|