ok/jj
1
0
Fork 0
forked from mirrors/jj
jj/tests/test_commit_template.rs

142 lines
6.1 KiB
Rust
Raw Normal View History

// Copyright 2023 The Jujutsu Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
use common::TestEnvironment;
use regex::Regex;
pub mod common;
#[test]
fn test_log_author_timestamp() {
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", "author.timestamp()"]);
insta::assert_snapshot!(stdout, @r###"
@ 2001-02-03 04:05:09.000 +07:00
o 2001-02-03 04:05:07.000 +07:00
o 1970-01-01 00:00:00.000 +00:00
"###);
}
#[test]
fn test_log_author_timestamp_ago() {
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", "author.timestamp().ago()"]);
let line_re = Regex::new(r"@|o [0-9]+ years ago").unwrap();
assert!(
stdout.lines().all(|x| line_re.is_match(x)),
"expected every line to match regex"
);
}
#[test]
fn test_log_default() {
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", "description 1"]);
test_env.jj_cmd_success(&repo_path, &["branch", "create", "my-branch"]);
// Test default log output format
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["log"]), @r###"
@ ffdaa62087a2 test.user@example.com 2001-02-03 04:05:09.000 +07:00 my-branch 9de54178d59d
| description 1
o 9a45c67d3e96 test.user@example.com 2001-02-03 04:05:08.000 +07:00 4291e264ae97
| add a file
o 000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
(no description set)
"###);
// Color
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "--color=always"]);
insta::assert_snapshot!(stdout, @r###"
@ ffdaa62087a2 test.user@example.com 2001-02-03 04:05:09.000 +07:00 my-branch 9de54178d59d
| description 1
formatter: use `crossterm` for colors Let's use `crossterm` to make `ColorFormatter` a little more readable, and maybe also more portable. This uses the `SetForegroundColor()` function, which uses the escapes for 256-color support (code 38) instead of the 8-color escapes (codes 30-37) combined with bold/bright (code 1) we were using before. IIUC, most terminals support the 16 base colors when using the 256-color escape even if they don't support all the 256 colors. It seems like an improvement to use actual color codes for the bright colors too, instead of assuming that terminals render bold as bright (even though most terminals do). Before this commit, we relied on ANSI escape 1 - which is specified to make the font bold - to make the color brighter. That's why we call the colors "bright blue" etc. When we switch from using code 30-37 to using 38 to let our color config just control the color (not using escape1), we therefore lose the bold font on many terminals (at least in iTerm2 and in the terminal application on my Debian work computer). As a workaround, I made us still use escape 1 when the bright colors are used. I'll make boldness a separately configurable attribute soon. Then we'll be able to remove this hack. With the switch to `crossterm`, we also reset just the foreground color (code 39) instead of resetting all attributes (code 0). That also seems like an improvement, probably making it easier for us to later support different background colors, underlining, etc.
2022-12-27 07:23:19 +00:00
o 9a45c67d3e96 test.user@example.com 2001-02-03 04:05:08.000 +07:00 4291e264ae97
| add a file
o 000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
(no description set)
"###);
// Color without graph
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "--color=always", "--no-graph"]);
insta::assert_snapshot!(stdout, @r###"
ffdaa62087a2 test.user@example.com 2001-02-03 04:05:09.000 +07:00 my-branch 9de54178d59d
description 1
9a45c67d3e96 test.user@example.com 2001-02-03 04:05:08.000 +07:00 4291e264ae97
add a file
000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
(no description set)
"###);
}
2023-01-10 06:26:19 +00:00
#[test]
fn test_log_default_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"]);
// No divergence
insta::assert_snapshot!(stdout, @r###"
@ 9a45c67d3e96 test.user@example.com 2001-02-03 04:05:08.000 +07:00 7a17d52e633c
| description 1
o 000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
(no description set)
"###);
// 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"]);
insta::assert_snapshot!(stdout, @r###"
Concurrent modification detected, resolving automatically.
o 9a45c67d3e96?? test.user@example.com 2001-02-03 04:05:10.000 +07:00 8979953d4c67
2023-01-10 06:26:19 +00:00
| description 2
| @ 9a45c67d3e96?? test.user@example.com 2001-02-03 04:05:08.000 +07:00 7a17d52e633c
2023-01-10 06:26:19 +00:00
|/ description 1
o 000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
(no description set)
"###);
// Color
let stdout = test_env.jj_cmd_success(&repo_path, &["log", "--color=always"]);
insta::assert_snapshot!(stdout, @r###"
formatter: use `crossterm` for colors Let's use `crossterm` to make `ColorFormatter` a little more readable, and maybe also more portable. This uses the `SetForegroundColor()` function, which uses the escapes for 256-color support (code 38) instead of the 8-color escapes (codes 30-37) combined with bold/bright (code 1) we were using before. IIUC, most terminals support the 16 base colors when using the 256-color escape even if they don't support all the 256 colors. It seems like an improvement to use actual color codes for the bright colors too, instead of assuming that terminals render bold as bright (even though most terminals do). Before this commit, we relied on ANSI escape 1 - which is specified to make the font bold - to make the color brighter. That's why we call the colors "bright blue" etc. When we switch from using code 30-37 to using 38 to let our color config just control the color (not using escape1), we therefore lose the bold font on many terminals (at least in iTerm2 and in the terminal application on my Debian work computer). As a workaround, I made us still use escape 1 when the bright colors are used. I'll make boldness a separately configurable attribute soon. Then we'll be able to remove this hack. With the switch to `crossterm`, we also reset just the foreground color (code 39) instead of resetting all attributes (code 0). That also seems like an improvement, probably making it easier for us to later support different background colors, underlining, etc.
2022-12-27 07:23:19 +00:00
o 9a45c67d3e96?? test.user@example.com 2001-02-03 04:05:10.000 +07:00 8979953d4c67
2023-01-10 06:26:19 +00:00
| description 2
| @ 9a45c67d3e96?? test.user@example.com 2001-02-03 04:05:08.000 +07:00 7a17d52e633c
|/ description 1
o 000000000000 1970-01-01 00:00:00.000 +00:00 000000000000
2023-01-10 06:26:19 +00:00
(no description set)
"###);
}