mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-01-15 00:44:33 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 13
jj/tests/test_log_command.rs

969 lines
30 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
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +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.
log: warn if the provided path looks like a revset
2022-11-18 23:41:35 +00:00
use common::{get_stderr_string, get_stdout_string, TestEnvironment};
tests: move `testutils` from `src/` to `tests/`
2022-03-30 17:47:11 +00:00
pub mod common;
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
cli: require revision arguments to be non-empty strings I can't see any reason the user would want to specify revisions matching the empty string, so let's disallow it. I created a custom type for revision arguments instead of repeating `value_parser = NonEmptyStringValueParser::new()`.
2022-11-28 14:32:44 +00:00
#[test]
fn test_log_with_empty_revision() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
let stderr = test_env.jj_cmd_cli_error(&repo_path, &["log", "-r="]);
insta::assert_snapshot!(stderr, @r###"
error: The argument '--revisions <REVISIONS>' requires a value but none was supplied
For more information try '--help'
"###);
}
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
#[test]
fn test_log_with_or_without_diff() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file1"), "foo\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "add a file"]);
test_env.jj_cmd_success(&repo_path, &["new", "-m", "a new commit"]);
std::fs::write(repo_path.join("file1"), "foo\nbar\n").unwrap();
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description"]);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
o add a file
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "-p"]);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| Modified regular file file1:
| 1 1: foo
| 2: bar
o add a file
| Added regular file file1:
| 1: foo
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "--no-graph"]);
insta::assert_snapshot!(stdout, @r###"
a new commit
add a file
"###);
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
// `-p` for default diff output, `-s` for summary
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "-p", "-s"]);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| M file1
| Modified regular file file1:
| 1 1: foo
| 2: bar
o add a file
| A file1
| Added regular file file1:
| 1: foo
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
"###);
// `-s` for summary, `--git` for git diff (which implies `-p`)
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "-s", "--git"]);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| M file1
| diff --git a/file1 b/file1
| index 257cc5642c...3bd1f0e297 100644
| --- a/file1
| +++ b/file1
| @@ -1,1 +1,2 @@
| foo
| +bar
o add a file
| A file1
| diff --git a/file1 b/file1
| new file mode 100644
| index 0000000000..257cc5642c
| --- /dev/null
| +++ b/file1
| @@ -1,0 +1,1 @@
| +foo
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
"###);
// `-p` enables default "summary" output, so `-s` is noop
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
"description",
"-p",
"-s",
cli: rename `diff.format` to `ui.diff.format` I felt that the config is too narrow to have it's own top-level [diff] section, and I couldn't think of another good place to have it. I'm happy to hear other suggestions.
2023-02-06 06:42:27 +00:00
"--config-toml=ui.diff.format='summary'",
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
],
);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| M file1
o add a file
| A file1
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
"###);
// `-p` enables default "color-words" diff output, so `--color-words` is noop
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "-p", "--color-words"],
);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| Modified regular file file1:
| 1 1: foo
| 2: bar
o add a file
| Added regular file file1:
| 1: foo
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
"###);
// `--git` enables git diff, so `-p` is noop
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "--no-graph", "-p", "--git"],
);
insta::assert_snapshot!(stdout, @r###"
a new commit
diff --git a/file1 b/file1
index 257cc5642c...3bd1f0e297 100644
--- a/file1
+++ b/file1
@@ -1,1 +1,2 @@
foo
+bar
add a file
diff --git a/file1 b/file1
new file mode 100644
index 0000000000..257cc5642c
--- /dev/null
+++ b/file1
@@ -1,0 +1,1 @@
+foo
"###);
cli: make `log -s/--git` imply `-p` `log -s/--summary` and `log --git` without `-p` don't do anything. I also don't think it's very useful to pass these flags in an alias, where you would then sometimes also pass `-p` to see the diff summary in the output. We already have the `diff.format` config for that use case. So let's make both of these flags imply `-p`. I implemented it by making the `diff_format` variable an `Option<DiffFormat>`, which is set iff we should show a patch. That way we have the condition in one place, and the places we use it cannot forget to check it.
2022-05-13 05:20:10 +00:00
cli: allow multiple diff outputs "jj log -p --summary" now shows summary and color-words diff, like "hg log -p --stat". Handling of "-p" is tricky. I first considered "-p" would turn on the default diff output, but I found it would be confusing if "jj log -p --git" showed both color-words and git diffs. So the default format is inserted only if no --git nor --color-words is explicitly specified.
2022-12-13 12:24:24 +00:00
// Both formats enabled if `--git` and `--color-words` are explicitly specified
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
"description",
"--no-graph",
"-p",
"--git",
"--color-words",
],
);
insta::assert_snapshot!(stdout, @r###"
a new commit
diff --git a/file1 b/file1
index 257cc5642c...3bd1f0e297 100644
--- a/file1
+++ b/file1
@@ -1,1 +1,2 @@
foo
+bar
Modified regular file file1:
1 1: foo
2: bar
add a file
diff --git a/file1 b/file1
new file mode 100644
index 0000000000..257cc5642c
--- /dev/null
+++ b/file1
@@ -1,0 +1,1 @@
+foo
Added regular file file1:
1: foo
"###);
// `-s` with or without graph
cli: make `log -s/--git` imply `-p` `log -s/--summary` and `log --git` without `-p` don't do anything. I also don't think it's very useful to pass these flags in an alias, where you would then sometimes also pass `-p` to see the diff summary in the output. We already have the `diff.format` config for that use case. So let's make both of these flags imply `-p`. I implemented it by making the `diff_format` variable an `Option<DiffFormat>`, which is set iff we should show a patch. That way we have the condition in one place, and the places we use it cannot forget to check it.
2022-05-13 05:20:10 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "-s"]);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
| M file1
o add a file
| A file1
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: make `log -s/--git` imply `-p` `log -s/--summary` and `log --git` without `-p` don't do anything. I also don't think it's very useful to pass these flags in an alias, where you would then sometimes also pass `-p` to see the diff summary in the output. We already have the `diff.format` config for that use case. So let's make both of these flags imply `-p`. I implemented it by making the `diff_format` variable an `Option<DiffFormat>`, which is set iff we should show a patch. That way we have the condition in one place, and the places we use it cannot forget to check it.
2022-05-13 05:20:10 +00:00
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "--no-graph", "-s"],
);
insta::assert_snapshot!(stdout, @r###"
a new commit
M file1
add a file
A file1
"###);
// `--git` implies `-p`, with or without graph
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "-r", "@", "--git"],
);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
~ diff --git a/file1 b/file1
index 257cc5642c...3bd1f0e297 100644
--- a/file1
+++ b/file1
@@ -1,1 +1,2 @@
foo
+bar
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "-r", "@", "--no-graph", "--git"],
);
insta::assert_snapshot!(stdout, @r###"
a new commit
diff --git a/file1 b/file1
index 257cc5642c...3bd1f0e297 100644
--- a/file1
+++ b/file1
@@ -1,1 +1,2 @@
foo
+bar
"###);
cli: enable diff output by 'log --color-words' It doesn't make sense that --git implies -p, but --color-words doesn't.
2022-12-14 10:48:53 +00:00
// `--color-words` implies `-p`, with or without graph
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "-r", "@", "--color-words"],
);
insta::assert_snapshot!(stdout, @r###"
@ a new commit
~ Modified regular file file1:
1 1: foo
2: bar
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
"description",
"-r",
"@",
"--no-graph",
"--color-words",
],
);
insta::assert_snapshot!(stdout, @r###"
a new commit
Modified regular file file1:
1 1: foo
2: bar
"###);
log: add -p/--patch option to show diff along with commit meta data "log -p | less" is the option I often use with hg/git to find interesting bits from the changelog, and I think it's also valid with jj. Unlike "hg log -p --stat", "jj log -p --summary" does not show both diff summary and patch to reflect the internal structure. This behavoir is arguable and may be changed later. The logic of show_patch() is extracted from cmd_show().
2022-03-28 09:12:08 +00:00
}
cli: teach `log` flag to show commits in reverse order This adds a `--reversed` flag to `jj log` to show commits with later commits further down. It works both with and without the graph. Since the graph-drawing code is already independent of the relationship between commits, it doesn't need any updating.
2022-05-09 17:38:23 +00:00
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
#[test]
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
fn test_log_prefix_highlight_brackets() {
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
fn prefix_format(len: Option<usize>) -> String {
format!(
r#"
templater: migrate shortest_prefix_and_brackets() over shortest()
2023-02-06 06:43:24 +00:00
"Change " change_id.shortest({0}).with_brackets() " " description.first_line()
" " commit_id.shortest({0}).with_brackets() " " branches
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"#,
len.map(|l| l.to_string()).unwrap_or(String::default())
)
}
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
std::fs::write(repo_path.join("file"), "original file\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "initial"]);
test_env.jj_cmd_success(&repo_path, &["branch", "c", "original"]);
insta::assert_snapshot!(
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", "original", "-T", &prefix_format(Some(12))]),
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
@r###"
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@ Change 9[a45c67d3e96] initial b[a1a30916d29] original
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
~
"###
);
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
// Create a chain of 10 commits
for i in 1..10 {
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
test_env.jj_cmd_success(&repo_path, &["new", "-m", &format!("commit{i}")]);
std::fs::write(repo_path.join("file"), format!("file {i}\n")).unwrap();
}
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
// Create 2^3 duplicates of the chain
for _ in 0..3 {
test_env.jj_cmd_success(&repo_path, &["duplicate", "description(commit)"]);
}
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
insta::assert_snapshot!(
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", "original", "-T", &prefix_format(Some(12))]),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@r###"
o Change 9a4[5c67d3e96] initial ba1[a30916d29] original
~
"###
);
insta::assert_snapshot!(
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", ":@", "-T", &prefix_format(Some(12))]),
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c[3fb0af576] commit9 03f[51310b83e]
o Change fd[f57e73a939] commit8 f7[7fb1909080]
o Change fa9[213bcf78e] commit7 e7[15ad5db646]
o Change 0cff[a7997ffe] commit6 38[622e54e2e5]
o Change 1b[76972398e6] commit5 0cf4[2f60199c]
o Change 48[523d946ad2] commit4 9e[6015e4e622]
o Change 19[b790168e73] commit3 06f[34d9b1475]
o Change 8b12[d1f268f8] commit2 1f[99a5e19891]
o Change d0[43564ef936] commit1 7b[1f7dee65b4]
o Change 9a4[5c67d3e96] initial ba1[a30916d29] original
o Change 000[000000000] 000[000000000]
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
"###
);
insta::assert_snapshot!(
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", ":@", "-T", &prefix_format(Some(3))]),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c commit9 03f
o Change fd[f] commit8 f7[7]
o Change fa9 commit7 e7[1]
o Change 0cff commit6 38[6]
o Change 1b[7] commit5 0cf4
o Change 48[5] commit4 9e[6]
o Change 19[b] commit3 06f
o Change 8b12 commit2 1f[9]
o Change d0[4] commit1 7b[1]
o Change 9a4 initial ba1 original
o Change 000 000
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"###
);
insta::assert_snapshot!(
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", ":@", "-T", &prefix_format(None)]),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c commit9 03f
o Change fd commit8 f7
o Change fa9 commit7 e7
o Change 0cff commit6 38
o Change 1b commit5 0cf4
o Change 48 commit4 9e
o Change 19 commit3 06f
o Change 8b12 commit2 1f
o Change d0 commit1 7b
o Change 9a4 initial ba1 original
o Change 000 000
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"###
);
}
#[test]
fn test_log_prefix_highlight_styled() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
fn prefix_format(len: Option<usize>) -> String {
format!(
r#"
templater: rename shortest_styled_prefix() to shortest() Now it is the true "shortest prefix" function with the default parameter, so let's simply call it "shortest()".
2023-02-06 06:37:32 +00:00
"Change " change_id.shortest({0}) " " description.first_line()
" " commit_id.shortest({0}) " " branches
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"#,
len.map(|l| l.to_string()).unwrap_or(String::default())
)
}
std::fs::write(repo_path.join("file"), "original file\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "initial"]);
test_env.jj_cmd_success(&repo_path, &["branch", "c", "original"]);
insta::assert_snapshot!(
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", "original", "-T", &prefix_format(Some(12))]),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@r###"
@ Change 9a45c67d3e96 initial ba1a30916d29 original
~
"###
);
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
// Create a chain of 10 commits
for i in 1..10 {
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
test_env.jj_cmd_success(&repo_path, &["new", "-m", &format!("commit{i}")]);
std::fs::write(repo_path.join("file"), format!("file {i}\n")).unwrap();
}
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
// Create 2^3 duplicates of the chain
for _ in 0..3 {
test_env.jj_cmd_success(&repo_path, &["duplicate", "description(commit)"]);
}
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
insta::assert_snapshot!(
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", "original", "-T", &prefix_format(Some(12))]),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@r###"
o Change 9a45c67d3e96 initial ba1a30916d29 original
~
"###
);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"--color=always",
"log",
"-r",
"@-----------..@",
"-T",
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
&prefix_format(Some(12)),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
],
);
insta::assert_snapshot!(stdout,
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c3fb0af576 commit9 03f51310b83e
o Change fdf57e73a939 commit8 f77fb1909080
o Change fa9213bcf78e commit7 e715ad5db646
o Change 0cffa7997ffe commit6 38622e54e2e5
o Change 1b76972398e6 commit5 0cf42f60199c
o Change 48523d946ad2 commit4 9e6015e4e622
o Change 19b790168e73 commit3 06f34d9b1475
o Change 8b12d1f268f8 commit2 1f99a5e19891
o Change d043564ef936 commit1 7b1f7dee65b4
o Change 9a45c67d3e96 initial ba1a30916d29 original
o Change 000000000000 000000000000
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"###
);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"--color=always",
"log",
"-r",
"@-----------..@",
"-T",
&prefix_format(Some(3)),
],
);
insta::assert_snapshot!(stdout,
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c commit9 03f
o Change fdf commit8 f77
o Change fa9 commit7 e71
o Change 0cff commit6 386
o Change 1b7 commit5 0cf4
o Change 485 commit4 9e6
o Change 19b commit3 06f
o Change 8b12 commit2 1f9
o Change d04 commit1 7b1
o Change 9a4 initial ba1 original
o Change 000 000
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
"###
);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"--color=always",
"log",
"-r",
"@-----------..@",
"-T",
Templater: make `shortest` id functions default to 0 length This makes them print the shortest unique prefix only.
2023-02-06 05:38:54 +00:00
&prefix_format(None),
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
],
);
insta::assert_snapshot!(stdout,
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c commit9 03f
o Change fd commit8 f7
o Change fa9 commit7 e7
o Change 0cff commit6 38
o Change 1b commit5 0cf4
o Change 48 commit4 9e
o Change 19 commit3 06f
o Change 8b12 commit2 1f
o Change d0 commit1 7b
o Change 9a4 initial ba1 original
o Change 000 000
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
"###
);
}
#[test]
fn test_log_prefix_highlight_counts_hidden_commits() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
let prefix_format = r#"
templater: migrate shortest_prefix_and_brackets() over shortest()
2023-02-06 06:43:24 +00:00
"Change " change_id.shortest(12).with_brackets() " " description.first_line()
" " commit_id.shortest(12).with_brackets() " " branches
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
"#;
std::fs::write(repo_path.join("file"), "original file\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "initial"]);
test_env.jj_cmd_success(&repo_path, &["branch", "c", "original"]);
insta::assert_snapshot!(
test_env.jj_cmd_success(&repo_path, &["log", "-r", "all()", "-T", prefix_format]),
@r###"
Templater: Give `shortest` id functions a `total_len` argument.
2023-01-21 04:56:34 +00:00
@ Change 9[a45c67d3e96] initial b[a1a30916d29] original
o Change 0[00000000000] 0[00000000000]
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
"###
);
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
// Create 2^7 hidden commits
test_env.jj_cmd_success(&repo_path, &["new", "root", "-m", "extra"]);
for _ in 0..7 {
test_env.jj_cmd_success(&repo_path, &["duplicate", "description(extra)"]);
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
}
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["abandon", "description(extra)"]);
// The first commit's unique prefix became longer.
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
insta::assert_snapshot!(
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-T", prefix_format]),
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
@ Change 39c3[fb0af576] 44[4c3c5066d3]
| o Change 9a[45c67d3e96] initial ba[1a30916d29] original
|/
o Change 00[0000000000] 00[0000000000]
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
"###
);
insta::assert_snapshot!(
test_env.jj_cmd_failure(&repo_path, &["log", "-r", "d", "-T", prefix_format]),
@r###"
Error: Commit or change id prefix "d" is ambiguous
"###
);
insta::assert_snapshot!(
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
test_env.jj_cmd_success(&repo_path, &["log", "-r", "d0", "-T", prefix_format]),
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
@r###"
tests: reduce subprocessing in unique-prefix tests The unique-prefixe tests are typically the slowest tests. Here's the end of my `cargo nextest --workspace` output (from an arbitrary run, not best-of-5 or anything): PASS [ 5.129s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 5.220s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 8.523s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits These tests create 50-100 commits in a loop. I think much of it comes from the subprocessing and/or the repeated loading of the repository in the subprocesses. Rewriting them to use `jj duplicate` for creating many commits at once speeds them up. Here are the timings after: PASS [ 2.323s] jujutsu::test_log_command test_log_prefix_highlight_styled PASS [ 2.330s] jujutsu::test_log_command test_log_prefix_highlight_brackets PASS [ 3.773s] jujutsu::test_log_command test_log_prefix_highlight_counts_hidden_commits
2023-02-06 07:06:44 +00:00
o Change a70[78fc7d293] extra d0[947f34cec4]
Templater: naive implementation of shortest prefix highlight for ids This creates a templater function `short_underscore_prefix` for commit and change ids. It is similar to `short` function, but shows one fewer hexadecimal digit and inserts an underscore after the shortest unique prefix. Highlighting with an underline and perhaps color/bold will be in a follow-up PR. The implementation is quadratic, a simple comparison of each id with every other id. It is replaced in a subsequent commit. The problem with it is that, while it works fine for a `jj`-sized repo, it becomes is painfully slow with a repo the size of git/git. Still, this naive implemenation is included here since it's simple, and could be used as a reference implementation. The `shortest_unique_prefix_length` function goes into `repo.rs` since that's convenient for follow-up commits in this PR to have nicer diffs.
2023-01-03 00:24:00 +00:00
~
"###
);
}
templater: inline extract_entire_prefix_and_trimmed_tail() and simplify
2023-02-06 06:52:16 +00:00
#[test]
fn test_log_shortest_length_parameter() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
insta::assert_snapshot!(
test_env.jj_cmd_success(&repo_path, &["log", "-T", "commit_id.shortest(0)"]), @r###"
@ 2
o 0
"###);
insta::assert_snapshot!(
test_env.jj_cmd_success(&repo_path, &["log", "-T", "commit_id.shortest(100)"]), @r###"
@ 230dd059e1b059aefc0da06a2e5a7dbf22362f22
o 0000000000000000000000000000000000000000
"###);
}
Test `jj log` for divergent commits It turns out we did not have tests that would catch `jj log` failing to mark divergent commits.
2023-01-02 07:09:38 +00:00
#[test]
fn test_log_divergence() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file"), "foo\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "description 1"]);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
r#"description.first_line() if(divergent, " !divergence!")"#,
],
);
// No divergence
insta::assert_snapshot!(stdout, @r###"
@ description 1
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
Test `jj log` for divergent commits It turns out we did not have tests that would catch `jj log` failing to mark divergent commits.
2023-01-02 07:09:38 +00:00
"###);
// Create divergence
test_env.jj_cmd_success(
&repo_path,
&["describe", "-m", "description 2", "--at-operation", "@-"],
);
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
r#"description.first_line() if(divergent, " !divergence!")"#,
],
);
insta::assert_snapshot!(stdout, @r###"
Concurrent modification detected, resolving automatically.
o description 2 !divergence!
| @ description 1 !divergence!
|/
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
Test `jj log` for divergent commits It turns out we did not have tests that would catch `jj log` failing to mark divergent commits.
2023-01-02 07:09:38 +00:00
"###);
}
cli: teach `log` flag to show commits in reverse order This adds a `--reversed` flag to `jj log` to show commits with later commits further down. It works both with and without the graph. Since the graph-drawing code is already independent of the relationship between commits, it doesn't need any updating.
2022-05-09 17:38:23 +00:00
#[test]
fn test_log_reversed() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "first"]);
test_env.jj_cmd_success(&repo_path, &["new", "-m", "second"]);
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "--reversed"]);
insta::assert_snapshot!(stdout, @r###"
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
cli: teach `log` flag to show commits in reverse order This adds a `--reversed` flag to `jj log` to show commits with later commits further down. It works both with and without the graph. Since the graph-drawing code is already independent of the relationship between commits, it doesn't need any updating.
2022-05-09 17:38:23 +00:00
o first
@ second
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "--reversed", "--no-graph"],
);
insta::assert_snapshot!(stdout, @r###"
first
second
"###);
}
cli: add basic support for 'jj log PATH' In the current implementation, tree is diffed twice if both PATH and -p are specified. If this adds significant cost, we'll need to reimplement it without using a revset abstraction (or maybe adjust revset/graph API.)
2022-09-13 07:26:23 +00:00
#[test]
fn test_log_filtered_by_path() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file1"), "foo\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "first"]);
test_env.jj_cmd_success(&repo_path, &["new", "-m", "second"]);
std::fs::write(repo_path.join("file1"), "foo\nbar\n").unwrap();
std::fs::write(repo_path.join("file2"), "baz\n").unwrap();
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "file1"]);
insta::assert_snapshot!(stdout, @r###"
@ second
o first
~
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "file2"]);
insta::assert_snapshot!(stdout, @r###"
@ second
~
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", "description", "-s", "file1"]);
insta::assert_snapshot!(stdout, @r###"
@ second
| M file1
o first
~ A file1
"###);
let stdout = test_env.jj_cmd_success(
&repo_path,
&["log", "-T", "description", "-s", "file2", "--no-graph"],
);
insta::assert_snapshot!(stdout, @r###"
second
A file2
"###);
revset: implement file(pattern[, candidates]) predicate The name "file()" is just copied from hg. I'm not sure if it's good in jj's context, but I couldn't find a better name.
2022-10-23 04:14:00 +00:00
// file() revset doesn't filter the diff.
let stdout = test_env.jj_cmd_success(
&repo_path,
&[
"log",
"-T",
"description",
"-s",
"-rfile(file2)",
"--no-graph",
],
);
insta::assert_snapshot!(stdout, @r###"
second
M file1
A file2
"###);
cli: add basic support for 'jj log PATH' In the current implementation, tree is diffed twice if both PATH and -p are specified. If this adds significant cost, we'll need to reimplement it without using a revset abstraction (or maybe adjust revset/graph API.)
2022-09-13 07:26:23 +00:00
}
add default log revset configuration setting
2022-10-01 15:09:32 +00:00
log: warn if the provided path looks like a revset
2022-11-18 23:41:35 +00:00
#[test]
fn test_log_warn_path_might_be_revset() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file1"), "foo\n").unwrap();
// Don't warn if the file actually exists.
let assert = test_env
.jj_cmd(&repo_path, &["log", "file1", "-T", "description"])
.assert()
.success();
insta::assert_snapshot!(get_stdout_string(&assert), @r###"
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
@
log: warn if the provided path looks like a revset
2022-11-18 23:41:35 +00:00
~
"###);
insta::assert_snapshot!(get_stderr_string(&assert), @"");
// Warn for `jj log .` specifically, for former Mercurial users.
let assert = test_env
.jj_cmd(&repo_path, &["log", ".", "-T", "description"])
.assert()
.success();
insta::assert_snapshot!(get_stdout_string(&assert), @r###"
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
@
log: warn if the provided path looks like a revset
2022-11-18 23:41:35 +00:00
~
"###);
insta::assert_snapshot!(get_stderr_string(&assert), @r###"warning: The argument "." is being interpreted as a path, but this is often not useful because all non-empty commits touch '.'. If you meant to show the working copy commit, pass -r '@' instead."###);
// ...but checking `jj log .` makes sense in a subdirectory.
let subdir = repo_path.join("dir");
std::fs::create_dir_all(&subdir).unwrap();
let assert = test_env.jj_cmd(&subdir, &["log", "."]).assert().success();
insta::assert_snapshot!(get_stdout_string(&assert), @"");
insta::assert_snapshot!(get_stderr_string(&assert), @"");
// Warn for `jj log @` instead of `jj log -r @`.
let assert = test_env
.jj_cmd(&repo_path, &["log", "@", "-T", "description"])
.assert()
.success();
insta::assert_snapshot!(get_stdout_string(&assert), @"");
insta::assert_snapshot!(get_stderr_string(&assert), @r###"
warning: The argument "@" is being interpreted as a path. To specify a revset, pass -r "@" instead.
"###);
// Warn when there's no path with the provided name.
let assert = test_env
.jj_cmd(&repo_path, &["log", "file2", "-T", "description"])
.assert()
.success();
insta::assert_snapshot!(get_stdout_string(&assert), @"");
insta::assert_snapshot!(get_stderr_string(&assert), @r###"
warning: The argument "file2" is being interpreted as a path. To specify a revset, pass -r "file2" instead.
"###);
// If an explicit revision is provided, then suppress the warning.
let assert = test_env
.jj_cmd(&repo_path, &["log", "@", "-r", "@", "-T", "description"])
.assert()
.success();
insta::assert_snapshot!(get_stdout_string(&assert), @"");
insta::assert_snapshot!(get_stderr_string(&assert), @r###"
"###);
}
add default log revset configuration setting
2022-10-01 15:09:32 +00:00
#[test]
fn test_default_revset() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file1"), "foo\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "add a file"]);
// Set configuration to only show the root commit.
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
test_env.add_config(r#"ui.default-revset = "root""#);
add default log revset configuration setting
2022-10-01 15:09:32 +00:00
// Log should only contain one line (for the root commit), and not show the
// commit created above.
assert_eq!(
1,
test_env
.jj_cmd_success(&repo_path, &["log", "-T", "commit_id"])
.lines()
.count()
);
}
feature: support relative timestamps as a config option
2022-11-26 01:33:24 +00:00
cli: load configs from .jj/repo/config.toml Since per-repo config may contain CLI settings, it must be visible to CLI. Therefore, UserSettings::with_repo() -> RepoSettings isn't used, and its implementation is nullified by this commit. #616
2023-01-02 05:18:38 +00:00
#[test]
fn test_default_revset_per_repo() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file1"), "foo\n").unwrap();
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "add a file"]);
// Set configuration to only show the root commit.
std::fs::write(
repo_path.join(".jj/repo/config.toml"),
r#"ui.default-revset = "root""#,
)
.unwrap();
// Log should only contain one line (for the root commit), and not show the
// commit created above.
assert_eq!(
1,
test_env
.jj_cmd_success(&repo_path, &["log", "-T", "commit_id"])
.lines()
.count()
);
}
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
#[test]
fn test_graph_template_color() {
// Test that color codes from a multi-line template don't span the graph lines.
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_success(
&repo_path,
&["describe", "-m", "first line\nsecond line\nthird line"],
);
test_env.jj_cmd_success(&repo_path, &["new", "-m", "single line"]);
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#"[colors]
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
description = "red"
"working_copy description" = "green"
"#,
);
// First test without color for comparison
cli: use label() to highlight "working_copy" commit in log template I think this is a proper way to label the working-copy commit. This also fixes "jj obslog" output, but I don't think anyone would care.
2023-02-03 03:49:40 +00:00
let template = r#"label(if(current_working_copy, "working_copy"), description)"#;
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T", template]);
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
insta::assert_snapshot!(stdout, @r###"
@ single line
o first line
| second line
| third line
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
"###);
cli: use label() to highlight "working_copy" commit in log template I think this is a proper way to label the working-copy commit. This also fixes "jj obslog" output, but I don't think anyone would care.
2023-02-03 03:49:40 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["--color=always", "log", "-T", template]);
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
insta::assert_snapshot!(stdout, @r###"
formatter: reset color around newlines There are several reasons for this: * We can more easily skip styling a trailing blank line, which other internal code then can correctly detect as having a trailing newline. This fixes the TODO in tests/test_commit_template.rs. * Some tools (like `less -R`) add an extra newline if the final character is not a newline (e.g. if there's a color reset after it), which led to an annoying blank line after the diff summary in e.g. `jj status`. * Since each line is styled independently, you get all the necessary escapes even when grepping through the output. * Some terminals extend background color to the end of the terminal (i.e. past the newline character), which is probably not what the user wanted. * Some tools (like `less -R`) get confused and lose coloring of lines after a newline.
2023-01-13 18:09:09 +00:00
@ single line
o first line
| second line
| third line
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
log: add test showing bugs in graph when the template uses color
2023-01-13 07:55:52 +00:00
"###);
}
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
#[test]
fn test_graph_styles() {
// Test that different graph styles are available.
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_success(&repo_path, &["commit", "-m", "initial"]);
test_env.jj_cmd_success(&repo_path, &["commit", "-m", "main branch 1"]);
test_env.jj_cmd_success(&repo_path, &["describe", "-m", "main branch 2"]);
test_env.jj_cmd_success(
&repo_path,
&["new", "-m", "side branch\nwith\nlong\ndescription"],
);
test_env.jj_cmd_success(
&repo_path,
&["new", "-m", "merge", r#"description("main branch 1")"#, "@"],
);
// Default (legacy) style
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T=description"]);
insta::assert_snapshot!(stdout, @r###"
@ merge
|\
o | side branch
| | with
| | long
| | description
o | main branch 2
|/
o main branch 1
o initial
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
"###);
// ASCII style
cli: rename `ui.graph.format` to `ui.graph.style` I think of it more as style than a format, so using `style` in the config key makes sense to me. I didn't bother making upgrades easy by supporting the old name since this was just released and only a few developers probably have it set.
2023-01-27 18:15:51 +00:00
test_env.add_config(r#"ui.graph.style = "ascii""#);
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T=description"]);
insta::assert_snapshot!(stdout, @r###"
@ merge
|\
o | side branch
| | with
| | long
| | description
o | main branch 2
|/
o main branch 1
o initial
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
"###);
// Large ASCII style
cli: rename `ui.graph.format` to `ui.graph.style` I think of it more as style than a format, so using `style` in the config key makes sense to me. I didn't bother making upgrades easy by supporting the old name since this was just released and only a few developers probably have it set.
2023-01-27 18:15:51 +00:00
test_env.add_config(r#"ui.graph.style = "ascii-large""#);
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T=description"]);
insta::assert_snapshot!(stdout, @r###"
@ merge
|\
| \
o | side branch
| | with
| | long
| | description
o | main branch 2
| /
|/
o main branch 1
o initial
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
"###);
// Curved style
cli: rename `ui.graph.format` to `ui.graph.style` I think of it more as style than a format, so using `style` in the config key makes sense to me. I didn't bother making upgrades easy by supporting the old name since this was just released and only a few developers probably have it set.
2023-01-27 18:15:51 +00:00
test_env.add_config(r#"ui.graph.style = "curved""#);
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T=description"]);
insta::assert_snapshot!(stdout, @r###"
@ merge
├─╮
o │ side branch
│ │ with
│ │ long
│ │ description
o │ main branch 2
├─╯
o main branch 1
o initial
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
"###);
// Square style
cli: rename `ui.graph.format` to `ui.graph.style` I think of it more as style than a format, so using `style` in the config key makes sense to me. I didn't bother making upgrades easy by supporting the old name since this was just released and only a few developers probably have it set.
2023-01-27 18:15:51 +00:00
test_env.add_config(r#"ui.graph.style = "square""#);
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "-T=description"]);
insta::assert_snapshot!(stdout, @r###"
@ merge
├─┐
o │ side branch
│ │ with
│ │ long
│ │ description
o │ main branch 2
├─┘
o main branch 1
o initial
templater: do not complete "(no commit description)" by default This allows us to use "if(description,)" to test empty description. And I think this change is unavoidable if we want to add support for commit template.
2023-01-31 09:17:46 +00:00
o
graphlog: enable Sapling's graph styles by default I would also rename the feature, but I hope we can instead soon make it a non-optional dependency and delete the feature.
2023-01-27 06:33:24 +00:00
"###);
}
Reference in a new issue Copy permalink