ok/jj
1
0
Fork 0
forked from mirrors/jj
Code Pull requests Activity
jj/cli/tests/test_resolve_command.rs

984 lines
35 KiB
Rust
Raw Normal View History

Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
// Copyright 2022 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 std::path::Path;
test_conflicts and test_resolve_command: use `indoc!` to indent conflict markers in tests Apart from (IMO) looking nicer, this will also sidestep the potential problem that if the file contains actual jj conflict markers (`>>>>>>>` in the beginning of a line, for example), jj would currently have trouble materializing and subsequently parsing conflicts in the file if it actually became conflicted. I'll demo this bug in either this or a subsequent PR. It's the kind of bug that sounds serious in theory but might never cause a problem in practice. After this PR, only `docs/tutorial.md` has a conflict marker that's not indented. There's only one there, so hopefully it won't be too much of a pain to deal with. I also indented other strings in `test_conflicts.rs`. IMO, this looks nice and more consistent with the `insta::assert_snapshot` output. I didn't spend the time to do the same for `test_resolve_command`.
2024-03-23 02:34:28 +00:00
use indoc::indoc;
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
use crate::common::TestEnvironment;
fn create_commit(
test_env: &TestEnvironment,
repo_path: &Path,
name: &str,
parents: &[&str],
files: &[(&str, &str)],
) {
if parents.is_empty() {
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(repo_path, &["new", "root()", "-m", name]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
} else {
let mut args = vec!["new", "-m", name];
args.extend(parents);
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(repo_path, &args);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
for (name, content) in files {
std::fs::write(repo_path.join(name), content).unwrap();
}
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_ok(repo_path, &["bookmark", "create", name]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
everything: Rename `branches` to `bookmarks` Jujutsu's branches do not behave like Git branches, which is a major hurdle for people adopting it from Git. They rather behave like Mercurial's (hg) bookmarks. We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord, where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name the current mechanism. This may be hard break for current `jj branch` users, but it will immensly help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]` config option is currently left alone, to force not another large config update for users, since the last time this happened was when `jj log -T show` was removed, which immediately resulted in breaking users and introduced soft deprecations. This name change will also make it easier to introduce Topics (#3402) as _topological branches_ with a easier model. This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from me being lazy or thankfully pointed out by reviewers.
2024-08-21 19:59:15 +00:00
test_env.jj_cmd_success(repo_path, &["log", "-T", "bookmarks"])
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
#[test]
fn test_resolution() {
let mut test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[("file", "b\n")]);
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
@r###"
file 2-sided conflict
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("file")).unwrap()
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-base
+a
+++++++ Contents of side #2
b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let editor_script = test_env.set_up_fake_editor();
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Check that output file starts out empty and resolve the conflict
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
std::fs::write(
&editor_script,
["dump editor0", "write\nresolution\n"].join("\0"),
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["resolve"]);
cli: send status messages to stderr, specify stdout/stderr explicitly Many of &mut UI can be changed to immutable borrows, but I'm not gonna update them in this patch.
2023-10-10 11:07:06 +00:00
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli templates: include branches in short commit description They are shown next to the change and commit id, since they are other names the commit can be referred by. The description is separated from the branches by a ` | ` when there are branches, so that one can tell the branches from the description without color. The result looks like this: ![image](https://github.com/martinvonz/jj/assets/4123047/a38aff7b-2b47-49e6-8461-c42e8eb535a4)
2023-08-08 03:11:59 +00:00
Working copy now at: vruxwmqv e069f073 conflict | conflict
Parent commit : zsuskuln aa493daf a | a
Parent commit : royxmykx db6a4daf b | b
Extract `resolve_list` from `cmd_resolve`, tests, minor refactoring This is all in preparation for follow-up commit, which will change some of the new tests. The extracted function will be further expanded later.
2022-12-24 01:57:10 +00:00
Added 0 files, modified 1 files, removed 0 files
"###);
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(test_env.env_root().join("editor0")).unwrap(), @r###"
"###);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/file b/file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..88425ec521 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/file
+++ b/file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--base
-+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+resolution
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_cli_error(&repo_path, &["resolve", "--list"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@r###"
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
Error: No conflicts found at this revision
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
"###);
cli: add --tool=<name> option to diff/merge editing commands I didn't add e2e tests to all commands, but the added tests should cover diff_editor/diff_selector/merge_editor() calls. Closes #2575
2024-03-01 14:49:22 +00:00
// Try again with --tool=<name>
test_env.jj_cmd_ok(&repo_path, &["undo"]);
std::fs::write(&editor_script, "write\nresolution\n").unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&[
"resolve",
"--config-toml=ui.merge-editor='false'",
"--tool=fake-editor",
],
);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
Resolving conflicts in: file
Working copy now at: vruxwmqv 1a70c7c6 conflict | conflict
Parent commit : zsuskuln aa493daf a | a
Parent commit : royxmykx db6a4daf b | b
Added 0 files, modified 1 files, removed 0 files
"###);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
cli: add --tool=<name> option to diff/merge editing commands I didn't add e2e tests to all commands, but the added tests should cover diff_editor/diff_selector/merge_editor() calls. Closes #2575
2024-03-01 14:49:22 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/file b/file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..88425ec521 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/file
+++ b/file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--base
-+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+resolution
cli: add --tool=<name> option to diff/merge editing commands I didn't add e2e tests to all commands, but the added tests should cover diff_editor/diff_selector/merge_editor() calls. Closes #2575
2024-03-01 14:49:22 +00:00
"###);
insta::assert_snapshot!(test_env.jj_cmd_cli_error(&repo_path, &["resolve", "--list"]),
@r###"
Error: No conflicts found at this revision
"###);
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Check that the output file starts with conflict markers if
// `merge-tool-edits-conflict-markers=true`
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["undo"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@"");
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
std::fs::write(
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
&editor_script,
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
["dump editor1", "write\nresolution\n"].join("\0"),
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
&repo_path,
&[
"resolve",
"--config-toml",
"merge-tools.fake-editor.merge-tool-edits-conflict-markers=true",
],
);
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(test_env.env_root().join("editor1")).unwrap(), @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
-base
+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
"###);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/file b/file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..88425ec521 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/file
+++ b/file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--base
-+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+resolution
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
"###);
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Check that if merge tool leaves conflict markers in output file and
// `merge-tool-edits-conflict-markers=true`, these markers are properly parsed.
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["undo"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@"");
std::fs::write(
&editor_script,
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
[
"dump editor2",
test_conflicts and test_resolve_command: use `indoc!` to indent conflict markers in tests Apart from (IMO) looking nicer, this will also sidestep the potential problem that if the file contains actual jj conflict markers (`>>>>>>>` in the beginning of a line, for example), jj would currently have trouble materializing and subsequently parsing conflicts in the file if it actually became conflicted. I'll demo this bug in either this or a subsequent PR. It's the kind of bug that sounds serious in theory but might never cause a problem in practice. After this PR, only `docs/tutorial.md` has a conflict marker that's not indented. There's only one there, so hopefully it won't be too much of a pain to deal with. I also indented other strings in `test_conflicts.rs`. IMO, this looks nice and more consistent with the `insta::assert_snapshot` output. I didn't spend the time to do the same for `test_resolve_command`.
2024-03-23 02:34:28 +00:00
indoc! {"
write
<<<<<<<
%%%%%%%
-some
+fake
+++++++
conflict
>>>>>>>
"},
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
]
.join("\0"),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&[
"resolve",
"--config-toml",
"merge-tools.fake-editor.merge-tool-edits-conflict-markers=true",
],
);
cli: send status messages to stderr, specify stdout/stderr explicitly Many of &mut UI can be changed to immutable borrows, but I'm not gonna update them in this patch.
2023-10-10 11:07:06 +00:00
insta::assert_snapshot!(stdout, @"");
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
insta::assert_snapshot!(stderr, @r###"
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
Working copy now at: vruxwmqv 7699b9c3 conflict | (conflict) conflict
Parent commit : zsuskuln aa493daf a | a
Parent commit : royxmykx db6a4daf b | b
Added 0 files, modified 1 files, removed 0 files
There are unresolved conflicts at these paths:
file 2-sided conflict
cli: print a message about new and resolved conflicts When e.g. `jj rebase` results in new conflicts, it's useful for the user to learn about that without having to run `jj log` right after. This patch adds reporting of new conflicts created by an operation. It also add reporting of conflicts that were resolved or abandoned by the operation. There was no measurable performance impact when rebasing a single commit in the Linux kernel repo.
2023-11-20 02:10:39 +00:00
New conflicts appeared in these commits:
git_backend: add a README to conflicted commits When you use e.g. `git switch` to check out a conflicted commit, you're going to end up with the `.jjconflicts-*` directories in your working copy. It's probably not obvious what those mean. This patch adds a README file to the root tree to try to explain to users what's going on and how to recover. The authoritative information about conflicts is stored in the `jj:trees` commit header. The contents of conflicted commits is only used for preventing GC. We can therefore add contents to the tree without much consequence.
2024-04-21 19:37:19 +00:00
vruxwmqv 7699b9c3 conflict | (conflict) conflict
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
To resolve the conflicts, start by updating to it:
conflicts: Highlight change ids in rebase advice
2024-09-12 10:49:08 +00:00
jj new vruxwmqv
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
Then use `jj resolve`, or edit the conflict markers in the file directly.
cli_util: add missing word in conflict resolution instructions
2024-07-16 17:30:40 +00:00
Once the conflicts are resolved, you may want to inspect the result with `jj diff`.
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
Then run `jj squash` to move the resolution into the conflicted commit.
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
"###);
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(test_env.env_root().join("editor2")).unwrap(), @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
-base
+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
"###);
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Note the "Modified" below
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/file b/file
--- a/file
+++ b/file
@@ -1,7 +1,7 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--base
-+a
+-some
++fake
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-b
+conflict
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
@r###"
file 2-sided conflict
"###);
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Check that if merge tool leaves conflict markers in output file but
// `merge-tool-edits-conflict-markers=false` or is not specified,
// `jj` considers the conflict resolved.
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["undo"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@"");
std::fs::write(
&editor_script,
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
[
"dump editor3",
test_conflicts and test_resolve_command: use `indoc!` to indent conflict markers in tests Apart from (IMO) looking nicer, this will also sidestep the potential problem that if the file contains actual jj conflict markers (`>>>>>>>` in the beginning of a line, for example), jj would currently have trouble materializing and subsequently parsing conflicts in the file if it actually became conflicted. I'll demo this bug in either this or a subsequent PR. It's the kind of bug that sounds serious in theory but might never cause a problem in practice. After this PR, only `docs/tutorial.md` has a conflict marker that's not indented. There's only one there, so hopefully it won't be too much of a pain to deal with. I also indented other strings in `test_conflicts.rs`. IMO, this looks nice and more consistent with the `insta::assert_snapshot` output. I didn't spend the time to do the same for `test_resolve_command`.
2024-03-23 02:34:28 +00:00
indoc! {"
write
<<<<<<<
%%%%%%%
-some
+fake
+++++++
conflict
>>>>>>>
"},
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
]
.join("\0"),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["resolve"]);
cli: send status messages to stderr, specify stdout/stderr explicitly Many of &mut UI can be changed to immutable borrows, but I'm not gonna update them in this patch.
2023-10-10 11:07:06 +00:00
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli: add --tool=<name> option to diff/merge editing commands I didn't add e2e tests to all commands, but the added tests should cover diff_editor/diff_selector/merge_editor() calls. Closes #2575
2024-03-01 14:49:22 +00:00
Working copy now at: vruxwmqv 3166dfd2 conflict | conflict
cli templates: include branches in short commit description They are shown next to the change and commit id, since they are other names the commit can be referred by. The description is separated from the branches by a ` | ` when there are branches, so that one can tell the branches from the description without color. The result looks like this: ![image](https://github.com/martinvonz/jj/assets/4123047/a38aff7b-2b47-49e6-8461-c42e8eb535a4)
2023-08-08 03:11:59 +00:00
Parent commit : zsuskuln aa493daf a | a
Parent commit : royxmykx db6a4daf b | b
Extract `resolve_list` from `cmd_resolve`, tests, minor refactoring This is all in preparation for follow-up commit, which will change some of the new tests. The extracted function will be further expanded later.
2022-12-24 01:57:10 +00:00
Added 0 files, modified 1 files, removed 0 files
"###);
tests: use insta to test editor contents It's tedious to update editor expectation manually. Let's dump the actual content and test it after each command invocation.
2022-12-22 07:58:23 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(test_env.env_root().join("editor3")).unwrap(), @r###"
"###);
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
// Note the "Resolved" below
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/file b/file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..0610716cc1 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/file
+++ b/file
@@ -1,7 +1,7 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--base
-+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
-b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+<<<<<<<
+%%%%%%%
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+-some
++fake
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
++++++++
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+conflict
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
+>>>>>>>
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_cli_error(&repo_path, &["resolve", "--list"]),
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
@r###"
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
Error: No conflicts found at this revision
`jj resolve`: option to parse conflict markers + tests If this new option is not specified, we start with empty output file and trust the merge tool did a complete merge no matter what the file contains. Includes tests.
2022-10-31 02:41:19 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
// TODO: Check that running `jj new` and then `jj resolve -r conflict` works
// correctly.
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
fn check_resolve_produces_input_file(
test_env: &mut TestEnvironment,
repo_path: &Path,
test_resolve_command: accept filename in `check_resolve_produces_input_file`
2024-05-30 22:58:43 +00:00
filename: &str,
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
role: &str,
expected_content: &str,
) {
let editor_script = test_env.set_up_fake_editor();
std::fs::write(editor_script, format!("expect\n{expected_content}")).unwrap();
let merge_arg_config = format!(r#"merge-tools.fake-editor.merge-args = ["${role}"]"#);
// This error means that fake-editor exited successfully but did not modify the
// output file.
Remove insta::assert_snapshot that causes a failure with insta 1.22
2022-12-06 05:39:05 +00:00
// We cannot use `insta::assert_snapshot!` here after insta 1.22 due to
// https://github.com/mitsuhiko/insta/commit/745b45b. Hopefully, this will again become possible
// in the future. See also https://github.com/mitsuhiko/insta/issues/313.
assert_eq!(
test_resolve_command: accept filename in `check_resolve_produces_input_file`
2024-05-30 22:58:43 +00:00
test_env.jj_cmd_failure(
repo_path,
&["resolve", "--config-toml", &merge_arg_config, filename]
),
format!(
"Resolving conflicts in: {filename}\nError: Failed to resolve conflicts\nCaused by: \
The output file is either unchanged or empty after the editor quit (run with --debug \
to see the exact invocation).\n"
)
Remove insta::assert_snapshot that causes a failure with insta 1.22
2022-12-06 05:39:05 +00:00
);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
#[test]
fn test_normal_conflict_input_files() {
let mut test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[("file", "b\n")]);
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
@r###"
file 2-sided conflict
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("file")).unwrap()
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-base
+a
+++++++ Contents of side #2
b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
test_resolve_command: accept filename in `check_resolve_produces_input_file`
2024-05-30 22:58:43 +00:00
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "base", "base\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "left", "a\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "right", "b\n");
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
#[test]
fn test_baseless_conflict_input_files() {
let mut test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[("file", "b\n")]);
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
@r###"
file 2-sided conflict
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("file")).unwrap()
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
conflicts: replace missing files by empty in materialized conflict When we materialize modify/delete conflicts, we currently don't include any context lines. That's because modify/delete conflicts have only two sides, so there's no common base to compare to. Hunks that are unchanged on the "modify" side are therefore not considered conflicting, and since they they don't contribute new changes, they're simply skipped (here: https://github.com/martinvonz/jj/blob/3dfedf581458f88982289f58db884bc65f1e635b/lib/src/files.rs#L228-L230). It seems more useful to instead pretend that the missing side is an empty file. That way we'll get a conflict in the entire file. We can still decide later to make e.g. `jj resolve` prompt the user on modify/delete conflicts just like `hg resolve` does (or maybe it actually happens earlier there, I don't remember). Closes #1244.
2023-02-17 18:05:47 +00:00
+a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
"###);
test_resolve_command: accept filename in `check_resolve_produces_input_file`
2024-05-30 22:58:43 +00:00
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "base", "");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "left", "a\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "right", "b\n");
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
#[test]
fn test_too_many_parents() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[("file", "b\n")]);
create_commit(&test_env, &repo_path, "c", &["base"], &[("file", "c\n")]);
create_commit(&test_env, &repo_path, "conflict", &["a", "b", "c"], &[]);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
@r###"
file 3-sided conflict
"###);
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
// Test warning color
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list", "--color=always"]),
@r###"
formatter: don't write escape codes until we write text We often end up writing escape codes for one style and then immediately after, we write escape codes for another style. That seems harmless, but it's a little ugly. More importantly, it prepares for not emitting any escapes for turning off attributes at the end of formatted contents across multiple lines (see next commit).
2023-01-13 08:39:22 +00:00
file 3-sided conflict
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
let error = test_env.jj_cmd_failure(&repo_path, &["resolve"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(error, @r###"
cli: add "Hint: " or "Warning: " heading to almost all messages It's inconsistent that some warnings have headings and some don't, and it seems the choice is arbitrary. Let's unify the style. There are two exceptions: 1. continued line following labeled message, 2. "unrecognized response" followed by prompt.
2024-03-24 06:47:47 +00:00
Hint: Using default editor ':builtin'; run `jj config set --user ui.merge-editor :builtin` to disable this message.
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli: preserve source of user error, print source chain one by one "Caused by" lines are inserted before the hint because they are more strongly related to the error.
2024-01-31 11:45:03 +00:00
Error: Failed to resolve conflicts
Caused by: The conflict at "file" has 3 sides. At most 2 sides are supported.
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
"###);
}
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
#[test]
fn test_simplify_conflict_sides() {
merge_tools: simplify file conflicts before attempting to resolve
2024-05-30 22:58:45 +00:00
let mut test_env = TestEnvironment::default();
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
// Creates a 4-sided conflict, with fileA and fileB having different conflicts:
// fileA: A - B + C - B + B - B + B
// fileB: A - A + A - A + B - C + D
create_commit(
&test_env,
&repo_path,
"base",
&[],
&[("fileA", "base\n"), ("fileB", "base\n")],
);
create_commit(&test_env, &repo_path, "a1", &["base"], &[("fileA", "1\n")]);
create_commit(&test_env, &repo_path, "a2", &["base"], &[("fileA", "2\n")]);
create_commit(&test_env, &repo_path, "b1", &["base"], &[("fileB", "1\n")]);
create_commit(&test_env, &repo_path, "b2", &["base"], &[("fileB", "2\n")]);
create_commit(&test_env, &repo_path, "conflictA", &["a1", "a2"], &[]);
create_commit(&test_env, &repo_path, "conflictB", &["b1", "b2"], &[]);
create_commit(
&test_env,
&repo_path,
"conflict",
&["conflictA", "conflictB"],
&[],
);
conflicts: materialize simplified file conflicts
2024-05-30 22:58:36 +00:00
// Even though the tree-level conflict is a 4-sided conflict, each file is
// materialized as a 2-sided conflict.
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["debug", "tree"]),
@r###"
fileA: Ok(Conflicted([Some(File { id: FileId("d00491fd7e5bb6fa28c517a0bb32b8b506539d4d"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("0cfbf08886fca9a91cb753ec8734c84fcbe52c9f"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false })]))
fileB: Ok(Conflicted([Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("d00491fd7e5bb6fa28c517a0bb32b8b506539d4d"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("0cfbf08886fca9a91cb753ec8734c84fcbe52c9f"), executable: false })]))
"###);
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
print_conflicted_paths: simplify file conflicts before printing
2024-05-30 22:58:41 +00:00
fileA 2-sided conflict
fileB 2-sided conflict
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
"###);
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("fileA")).unwrap(), @r###"
<<<<<<< Conflict 1 of 1
conflicts: materialize simplified file conflicts
2024-05-30 22:58:36 +00:00
%%%%%%% Changes from base to side #1
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
-base
+1
+++++++ Contents of side #2
2
>>>>>>> Conflict 1 of 1 ends
"###);
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("fileB")).unwrap(), @r###"
<<<<<<< Conflict 1 of 1
conflicts: materialize simplified file conflicts
2024-05-30 22:58:36 +00:00
%%%%%%% Changes from base to side #1
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
-base
+1
conflicts: materialize simplified file conflicts
2024-05-30 22:58:36 +00:00
+++++++ Contents of side #2
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
2
>>>>>>> Conflict 1 of 1 ends
"###);
merge_tools: simplify file conflicts before attempting to resolve
2024-05-30 22:58:45 +00:00
// Conflict should be simplified before being handled by external merge tool.
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileA", "base", "base\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileA", "left", "1\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileA", "right", "2\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileB", "base", "base\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileB", "left", "1\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "fileB", "right", "2\n");
// Check that simplified conflicts are still parsed as conflicts after editing
// when `merge-tool-edits-conflict-markers=true`.
let editor_script = test_env.set_up_fake_editor();
std::fs::write(
editor_script,
indoc! {"
write
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-base_edited
+1_edited
+++++++ Contents of side #2
2_edited
>>>>>>> Conflict 1 of 1 ends
"},
)
.unwrap();
let (stdout, stderr) = test_env.jj_cmd_ok(
&repo_path,
&[
"resolve",
"--config-toml",
"merge-tools.fake-editor.merge-tool-edits-conflict-markers=true",
"fileB",
],
);
insta::assert_snapshot!(stdout, @"");
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
insta::assert_snapshot!(stderr, @r###"
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
Resolving conflicts in: fileB
merge_tools: simplify file conflicts before attempting to resolve
2024-05-30 22:58:45 +00:00
Working copy now at: nkmrtpmo 4b14662a conflict | (conflict) conflict
Parent commit : kmkuslsw 18c1fb00 conflictA | (conflict) (empty) conflictA
Parent commit : lylxulpl d11c92eb conflictB | (conflict) (empty) conflictB
Added 0 files, modified 1 files, removed 0 files
There are unresolved conflicts at these paths:
fileA 2-sided conflict
fileB 2-sided conflict
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
New conflicts appeared in these commits:
nkmrtpmo 4b14662a conflict | (conflict) conflict
To resolve the conflicts, start by updating to it:
jj new nkmrtpmo
Then use `jj resolve`, or edit the conflict markers in the file directly.
Once the conflicts are resolved, you may want to inspect the result with `jj diff`.
Then run `jj squash` to move the resolution into the conflicted commit.
"###);
merge_tools: simplify file conflicts before attempting to resolve
2024-05-30 22:58:45 +00:00
insta::assert_snapshot!(std::fs::read_to_string(repo_path.join("fileB")).unwrap(), @r###"
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-base_edited
+1_edited
+++++++ Contents of side #2
2_edited
>>>>>>> Conflict 1 of 1 ends
"###);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
fileA 2-sided conflict
fileB 2-sided conflict
tests: add tests showing that individual file conflicts are not simplified/deduplicated
2024-05-30 22:58:27 +00:00
"###);
}
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
#[test]
fn test_edit_delete_conflict_input_files() {
let mut test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[]);
std::fs::remove_file(repo_path.join("file")).unwrap();
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
file 2-sided conflict including 1 deletion
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(
std::fs::read_to_string(repo_path.join("file")).unwrap()
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
+++++++ Contents of side #1
conflicts: replace missing files by empty in materialized conflict When we materialize modify/delete conflicts, we currently don't include any context lines. That's because modify/delete conflicts have only two sides, so there's no common base to compare to. Hunks that are unchanged on the "modify" side are therefore not considered conflicting, and since they they don't contribute new changes, they're simply skipped (here: https://github.com/martinvonz/jj/blob/3dfedf581458f88982289f58db884bc65f1e635b/lib/src/files.rs#L228-L230). It seems more useful to instead pretend that the missing side is an empty file. That way we'll get a conflict in the entire file. We can still decide later to make e.g. `jj resolve` prompt the user on modify/delete conflicts just like `hg resolve` does (or maybe it actually happens earlier there, I don't remember). Closes #1244.
2023-02-17 18:05:47 +00:00
a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
%%%%%%% Changes from base to side #2
conflicts: preserve order of adds in materialized conflict We write conflict to the working copy by materializing them as conflict markers in a file. When the file has been modified (or just the mtime has changed), we parse the markers to reconstruct the conflict. For example, let's say we see this conflict marker: ``` <<<<<<< +++++++ b %%%%%%% -a +c >>>>>>> ``` Then we will create a hunk with ["a"] as removed and ["b", "c"] as added. Now, since commit b84be06c0822, when we materialize conflicts, we minimize the diff part of the marker (the `%%%%%%%` part). The problem is that that minimization may result in a different order of the positive conflict terms. That's particularly bad because we do the minimization per hunk, so we can end up reconstructing an input that never existed. This commit fixes the bug by only considering the next add and the one after that, and emitting either only the first with `%%%%%%%`, or both of them, with the first one in `++++++++` and the second one in `%%%%%%%`. Note that the recent fix to add context to modify/delete conflicts means that when we parse modified such conflicts, we'll always consider them resolved, since the expected adds/removes we pass will not match what's actually in the file. That doesn't seem so bad, and it's not obvious what the fix should be, so I'll leave that for later.
2023-02-18 06:29:30 +00:00
-base
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
"###);
test_resolve_command: accept filename in `check_resolve_produces_input_file`
2024-05-30 22:58:43 +00:00
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "base", "base\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "left", "a\n");
check_resolve_produces_input_file(&mut test_env, &repo_path, "file", "right", "");
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
}
#[test]
fn test_file_vs_dir() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "a", &["base"], &[("file", "a\n")]);
create_commit(&test_env, &repo_path, "b", &["base"], &[]);
std::fs::remove_file(repo_path.join("file")).unwrap();
std::fs::create_dir(repo_path.join("file")).unwrap();
// Without a placeholder file, `jj` ignores an empty directory
std::fs::write(repo_path.join("file").join("placeholder"), "").unwrap();
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
file 2-sided conflict including a directory
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
let error = test_env.jj_cmd_failure(&repo_path, &["resolve"]);
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
insta::assert_snapshot!(error, @r###"
cli: add "Hint: " or "Warning: " heading to almost all messages It's inconsistent that some warnings have headings and some don't, and it seems the choice is arbitrary. Let's unify the style. There are two exceptions: 1. continued line following labeled message, 2. "unrecognized response" followed by prompt.
2024-03-24 06:47:47 +00:00
Hint: Using default editor ':builtin'; run `jj config set --user ui.merge-editor :builtin` to disable this message.
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli: preserve source of user error, print source chain one by one "Caused by" lines are inserted before the hint because they are more strongly related to the error.
2024-01-31 11:45:03 +00:00
Error: Failed to resolve conflicts
Caused by: Only conflicts that involve normal files (not symlinks, not executable, etc.) are supported. Conflict summary for "file":
Mention path in message for `ConflictResolveError::NotNormalFilesError`.
2022-12-04 07:10:10 +00:00
Conflict:
Test basic `jj resolve` functionality
2022-11-27 07:22:34 +00:00
Removing file with id df967b96a579e45a18b8251732d16804b2e56a55
Adding file with id 78981922613b2afb6025042ff6bd878ac1994e85
Adding tree with id 133bb38fc4e4bf6b551f1f04db7e48f04cac2877
"###);
}
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
#[test]
fn test_description_with_dir_and_deletion() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "base", &[], &[("file", "base\n")]);
create_commit(&test_env, &repo_path, "edit", &["base"], &[("file", "b\n")]);
create_commit(&test_env, &repo_path, "dir", &["base"], &[]);
std::fs::remove_file(repo_path.join("file")).unwrap();
std::fs::create_dir(repo_path.join("file")).unwrap();
// Without a placeholder file, `jj` ignores an empty directory
std::fs::write(repo_path.join("file").join("placeholder"), "").unwrap();
create_commit(&test_env, &repo_path, "del", &["base"], &[]);
std::fs::remove_file(repo_path.join("file")).unwrap();
create_commit(
&test_env,
&repo_path,
"conflict",
&["edit", "dir", "del"],
&[],
);
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─┬─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ │ ○ del
│ ○ │ dir
revset_graph: group commits topologically The original idea was similar to Mercurial's "topo" sorting, but it was bad at handling merge-heavy history. In order to render merges of topic branches nicely, we need to prioritize branches at merge point, not at fork point. OTOH, we do also want to place unmerged branches as close to the fork point as possible. This commit implements the former requirement, and the latter will be addressed by the next commit. I think this is similar to Git's sorting logic described in the following blog post. In our case, the in-degree walk can be dumb since topological order is guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree integer value, which will be used in the next commit to resolve new heads as late as possible. https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve the index (or chronological) order. I tried beautify_graph() with prioritizing the @ commit, but the result seemed too aggressively reordered. Perhaps, for more complex history, beautify_graph() would produce a better result. For my wip branches (~30 branches, a couple of commits per branch), this works pretty well. #242
2023-07-16 10:47:46 +00:00
│ ├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ │ edit
revset_graph: group commits topologically The original idea was similar to Mercurial's "topo" sorting, but it was bad at handling merge-heavy history. In order to render merges of topic branches nicely, we need to prioritize branches at merge point, not at fork point. OTOH, we do also want to place unmerged branches as close to the fork point as possible. This commit implements the former requirement, and the latter will be addressed by the next commit. I think this is similar to Git's sorting logic described in the following blog post. In our case, the in-degree walk can be dumb since topological order is guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree integer value, which will be used in the next commit to resolve new heads as late as possible. https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve the index (or chronological) order. I tried beautify_graph() with prioritizing the @ commit, but the result seemed too aggressively reordered. Perhaps, for more complex history, beautify_graph() would produce a better result. For my wip branches (~30 branches, a couple of commits per branch), this works pretty well. #242
2023-07-16 10:47:46 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
"###);
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
file 3-sided conflict including 1 deletion and a directory
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
"###);
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
// Test warning color. The deletion is fine, so it's not highlighted
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list", "--color=always"]),
@r###"
formatter: don't write escape codes until we write text We often end up writing escape codes for one style and then immediately after, we write escape codes for another style. That seems harmless, but it's a little ugly. More importantly, it prepares for not emitting any escapes for turning off attributes at the end of formatted contents across multiple lines (see next commit).
2023-01-13 08:39:22 +00:00
file 3-sided conflict including 1 deletion and a directory
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
"###);
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
let error = test_env.jj_cmd_failure(&repo_path, &["resolve"]);
insta::assert_snapshot!(error, @r###"
cli: add "Hint: " or "Warning: " heading to almost all messages It's inconsistent that some warnings have headings and some don't, and it seems the choice is arbitrary. Let's unify the style. There are two exceptions: 1. continued line following labeled message, 2. "unrecognized response" followed by prompt.
2024-03-24 06:47:47 +00:00
Hint: Using default editor ':builtin'; run `jj config set --user ui.merge-editor :builtin` to disable this message.
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: file
cli: preserve source of user error, print source chain one by one "Caused by" lines are inserted before the hint because they are more strongly related to the error.
2024-01-31 11:45:03 +00:00
Error: Failed to resolve conflicts
Caused by: Only conflicts that involve normal files (not symlinks, not executable, etc.) are supported. Conflict summary for "file":
`jj resolve --list`: Add descriptions of conflict complexity The descriptions focus on adds, not the deletions. The deletions are used to compute the number of deleted files that must be sides of the conflict.
2023-01-05 00:34:56 +00:00
Conflict:
Removing file with id df967b96a579e45a18b8251732d16804b2e56a55
Removing file with id df967b96a579e45a18b8251732d16804b2e56a55
Adding file with id 61780798228d17af2d34fce4cfbdf35556832472
Adding tree with id 133bb38fc4e4bf6b551f1f04db7e48f04cac2877
"###);
}
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
#[test]
fn test_multiple_conflicts() {
let mut test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
let repo_path = test_env.env_root().join("repo");
create_commit(
&test_env,
&repo_path,
"base",
&[],
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
&[
(
"this_file_has_a_very_long_name_to_test_padding",
"first base\n",
),
("another_file", "second base\n"),
],
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
);
create_commit(
&test_env,
&repo_path,
"a",
&["base"],
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
&[
(
"this_file_has_a_very_long_name_to_test_padding",
"first a\n",
),
("another_file", "second a\n"),
],
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
);
create_commit(
&test_env,
&repo_path,
"b",
&["base"],
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
&[
(
"this_file_has_a_very_long_name_to_test_padding",
"first b\n",
),
("another_file", "second b\n"),
],
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
);
create_commit(&test_env, &repo_path, "conflict", &["a", "b"], &[]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
@ conflict
├─╮
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ b
○ │ a
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
├─╯
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ base
◆
cli: switch default graph style to be Sapling's curved style We seem to quite unanimously prefer this style, so let's make the default.
2023-02-09 02:53:47 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
std::fs::read_to_string(repo_path.join("this_file_has_a_very_long_name_to_test_padding")).unwrap()
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
-first base
+first a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
first b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
insta::assert_snapshot!(
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
std::fs::read_to_string(repo_path.join("another_file")).unwrap()
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
, @r###"
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
-second base
+second a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
+++++++ Contents of side #2
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
second b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
>>>>>>> Conflict 1 of 1 ends
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
another_file 2-sided conflict
this_file_has_a_very_long_name_to_test_padding 2-sided conflict
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
"###);
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
// Test colors
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list", "--color=always"]),
@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
another_file 2-sided conflict
this_file_has_a_very_long_name_to_test_padding 2-sided conflict
`jj resolve --list`: make output colorful The description is usually in yellow, which looks nice and neutral. If the conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 18:21:38 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
let editor_script = test_env.set_up_fake_editor();
// Check that we can manually pick which of the conflicts to resolve first
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
std::fs::write(&editor_script, "expect\n\0write\nresolution another_file\n").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["resolve", "another_file"]);
cli: send status messages to stderr, specify stdout/stderr explicitly Many of &mut UI can be changed to immutable borrows, but I'm not gonna update them in this patch.
2023-10-10 11:07:06 +00:00
insta::assert_snapshot!(stdout, @"");
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
insta::assert_snapshot!(stderr, @r###"
cli: display which file's conflicts are being resolved
2023-12-20 01:25:01 +00:00
Resolving conflicts in: another_file
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
Working copy now at: vruxwmqv 6a90e546 conflict | (conflict) conflict
Parent commit : zsuskuln de7553ef a | a
Parent commit : royxmykx f68bc2f0 b | b
Added 0 files, modified 1 files, removed 0 files
There are unresolved conflicts at these paths:
this_file_has_a_very_long_name_to_test_padding 2-sided conflict
cli: print a message about new and resolved conflicts When e.g. `jj rebase` results in new conflicts, it's useful for the user to learn about that without having to run `jj log` right after. This patch adds reporting of new conflicts created by an operation. It also add reporting of conflicts that were resolved or abandoned by the operation. There was no measurable performance impact when rebasing a single commit in the Linux kernel repo.
2023-11-20 02:10:39 +00:00
New conflicts appeared in these commits:
git_backend: add a README to conflicted commits When you use e.g. `git switch` to check out a conflicted commit, you're going to end up with the `.jjconflicts-*` directories in your working copy. It's probably not obvious what those mean. This patch adds a README file to the root tree to try to explain to users what's going on and how to recover. The authoritative information about conflicts is stored in the `jj:trees` commit header. The contents of conflicted commits is only used for preventing GC. We can therefore add contents to the tree without much consequence.
2024-04-21 19:37:19 +00:00
vruxwmqv 6a90e546 conflict | (conflict) conflict
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
To resolve the conflicts, start by updating to it:
conflicts: Highlight change ids in rebase advice
2024-09-12 10:49:08 +00:00
jj new vruxwmqv
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
Then use `jj resolve`, or edit the conflict markers in the file directly.
cli_util: add missing word in conflict resolution instructions
2024-07-16 17:30:40 +00:00
Once the conflicts are resolved, you may want to inspect the result with `jj diff`.
cli: print a hint about how to resolve conflicts This prints a hint about using `jj new <first conflicted commit>` and `jj squash` to resolve conflicts. The hint is printed whenever there are new or resolved conflicts. I hope this hint will be useful especially for new users so they know which commit to resolve conflicts in first. It may not be obvious that they should start with the bottommost one. I hope the hint will also be useful for more more experienced user by letting them just copy the printed command without first running `jj log` to find the right commit..
2023-11-30 07:02:18 +00:00
Then run `jj squash` to move the resolution into the conflicted commit.
cli: reorder updating and reporting for consistency. * See #4239 for details. * For now, update working copy before reporting repo changes, so that potential errors in reporting changes don't leave the repo in a stale state. Fixes: #4239
2024-09-21 16:08:19 +00:00
"###);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/another_file b/another_file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..a9fcc7d486 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/another_file
+++ b/another_file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--second base
-+second a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-second b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+resolution another_file
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
this_file_has_a_very_long_name_to_test_padding 2-sided conflict
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
`jj resolve`: List remaining conflicts (if any) on success This can be prevented by the new `--quiet` option.
2022-12-24 01:57:10 +00:00
// Repeat the above with the `--quiet` option.
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["undo"]);
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
std::fs::write(&editor_script, "expect\n\0write\nresolution another_file\n").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["resolve", "--quiet", "another_file"]);
cli: send status messages to stderr, specify stdout/stderr explicitly Many of &mut UI can be changed to immutable borrows, but I'm not gonna update them in this patch.
2023-10-10 11:07:06 +00:00
insta::assert_snapshot!(stdout, @"");
cli: add a global `--quiet` flag, which silences status messages Note that `jj resolve` already had its own `--quiet` flag. The output with `--quiet` for that command got a lot quieter with the global `--quiet` also taking effect. That seems reasonable to me.
2024-03-30 17:18:56 +00:00
insta::assert_snapshot!(stderr, @"");
`jj resolve`: List remaining conflicts (if any) on success This can be prevented by the new `--quiet` option.
2022-12-24 01:57:10 +00:00
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
// For the rest of the test, we call `jj resolve` several times in a row to
// resolve each conflict in the order it chooses.
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["undo"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
@"");
std::fs::write(
&editor_script,
"expect\n\0write\nfirst resolution for auto-chosen file\n",
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["resolve"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/another_file b/another_file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..7903e1c1c7 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/another_file
+++ b/another_file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--second base
-+second a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-second b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+first resolution for auto-chosen file
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["resolve", "--list"]),
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
@r###"
`jj resolve --list`: make output aligned If all file names are short enough, this will align the conflict description at 4 spaces past the longest file name, as follows. ``` src/templater.rs 2-sided conflict src/templater_parsers.rs 2-sided conflict ``` If there is a long file name, conflict descriptions will either start or column 35 or one space from a file name, whichever is later. Previously, a single tab was used to separate file name from conflict description. This didn't look as nice as I hoped when multiple files are involved. I also don't think `jj` generally uses tabs in output. The tab uncovered a bug in a watcher program I was using.
2023-01-07 19:09:55 +00:00
this_file_has_a_very_long_name_to_test_padding 2-sided conflict
Update test to prepare for next commit
2023-01-07 19:09:55 +00:00
"###);
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
std::fs::write(
&editor_script,
"expect\n\0write\nsecond resolution for auto-chosen file\n",
)
.unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["resolve"]);
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff", "--git"]),
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
@r###"
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
diff --git a/another_file b/another_file
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..7903e1c1c7 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/another_file
+++ b/another_file
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--second base
-+second a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-second b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+first resolution for auto-chosen file
diff --git a/this_file_has_a_very_long_name_to_test_padding b/this_file_has_a_very_long_name_to_test_padding
diff: fix typo in Git diff "index old..new" header Spotted while consolidating "index" line generation. Git appears to use ".." to separate hashes.
2024-07-14 10:26:07 +00:00
index 0000000000..f8c72adf17 100644
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--- a/this_file_has_a_very_long_name_to_test_padding
+++ b/this_file_has_a_very_long_name_to_test_padding
@@ -1,7 +1,1 @@
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-<<<<<<< Conflict 1 of 1
-%%%%%%% Changes from base to side #1
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
--first base
-+first a
conflicts.rs: label conflict number and sides next to conflict markers For example, ``` <<<<<<< Conflict 1 of 3 +++++++ Contents of side #1 left 3.1 left 3.2 left 3.3 %%%%%%% Changes from base to side #2 -line 3 +right 3.1 >>>>>>> ``` or ``` <<<<<<< Conflict 1 of 1 %%%%%%% Changes from base to side #1 -line 3 +right 3.1 +++++++ Contents of side #2 left 3.1 left 3.2 left 3.3 >>>>>>> ``` Currently, there is no way to disable these, this is TODO for a future PR. Other TODOs for future PRs: make these labels configurable. After that, we could support a `diff3/git`-like conflict format as well, in principle. Counting conflicts helps with knowing whether you fixed all the conflicts while you are in the editor. While labeling "side #1", etc, does not tell you the commit id or description as requested in #1176, I still think it's an improvement. Most importantly, I hope this will make `jj`'s conflict format less scary-looking for new users. I've used this for a bit, and I like it. Without the labels, I would see that the two conflicts have a different order of conflict markers, but I wouldn't be able to remember what that means. For longer diffs, it can be tricky for me to quickly tell that it's a diff as opposed to one of the sides. This also creates some hope of being able to navigate a conflict with more than 2 sides. Another not-so-secret goal for this is explained in https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The idea is a little weird, but I *think* it could be helpful, and I'd like to experiment with it.
2024-03-23 22:16:28 +00:00
-+++++++ Contents of side #2
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
-first b
conflicts: label closing delimeter with conflict number This follows up on https://github.com/martinvonz/jj/pull/3459 and adds a label to the closing delimeter of each conflict, e.g. "Conflict 1 of 3 ends". I didn't initially put any label at the ending delimeter since the starting delimeter is already marked with "Conflict 1 of 3". However, I'm now realizing that when I resolve conflicts, I usually go from top to bottom. The first thing I do is delete the starting conflict delimeter. It is when I get to the *end* of the conflict that I wonder whether there are any more conflicts left in the file.
2024-05-16 01:00:50 +00:00
->>>>>>> Conflict 1 of 1 ends
test_resolve_command: use `diff --git` for readability
2024-03-23 22:39:58 +00:00
+second resolution for auto-chosen file
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
insta::assert_snapshot!(test_env.jj_cmd_cli_error(&repo_path, &["resolve", "--list"]),
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
@r###"
Minimal version of `resolve --list` Simply lists conflicted files
2022-12-04 03:47:03 +00:00
Error: No conflicts found at this revision
Make optional the `path` argument to `resolve`, allow partial paths Also allows several paths to be specified. By default, `jj resolve` will find the first conflict that matches provided paths (if any) and try to resolve it.
2022-12-04 03:47:03 +00:00
"###);
insta::assert_snapshot!(test_env.jj_cmd_cli_error(&repo_path, &["resolve"]),
@r###"
Error: No conflicts found at this revision
"###);
}
Copy permalink