2022-11-26 23:57:50 +00:00
|
|
|
// Copyright 2022 The Jujutsu Authors
|
2022-03-30 17:38:25 +00:00
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// https://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
2023-02-10 05:48:47 +00:00
|
|
|
use std::path::Path;
|
|
|
|
|
2022-03-30 17:38:25 +00:00
|
|
|
use crate::common::TestEnvironment;
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_restore() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2024-05-17 19:49:25 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
|
2022-03-30 17:38:25 +00:00
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
std::fs::write(repo_path.join("file1"), "a\n").unwrap();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new"]);
|
2022-03-30 17:38:25 +00:00
|
|
|
std::fs::write(repo_path.join("file2"), "b\n").unwrap();
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["new"]);
|
2022-03-30 17:38:25 +00:00
|
|
|
std::fs::remove_file(repo_path.join("file1")).unwrap();
|
|
|
|
std::fs::write(repo_path.join("file2"), "c\n").unwrap();
|
|
|
|
std::fs::write(repo_path.join("file3"), "c\n").unwrap();
|
|
|
|
|
2023-08-01 03:18:19 +00:00
|
|
|
// There is no `-r` argument
|
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["restore", "-r=@-"]);
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
Error: `jj restore` does not have a `--revision`/`-r` option. If you'd like to modify
|
|
|
|
the *current* revision, use `--from`. If you'd like to modify a *different* revision,
|
|
|
|
use `--to` or `--changes-in`.
|
|
|
|
"###);
|
|
|
|
|
2022-03-30 17:38:25 +00:00
|
|
|
// Restores from parent by default
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created kkmpptxz 370d81ea (empty) (no description set)
|
|
|
|
Working copy now at: kkmpptxz 370d81ea (empty) (no description set)
|
|
|
|
Parent commit : rlvkpnrz ef160660 (no description set)
|
2022-03-30 17:38:25 +00:00
|
|
|
Added 1 files, modified 1 files, removed 1 files
|
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
|
2023-02-20 08:45:23 +00:00
|
|
|
// Can restore another revision from its parents
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
2023-02-20 08:45:23 +00:00
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r=@-"]);
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
A file2
|
|
|
|
"###);
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "-c=@-"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created rlvkpnrz b9b6011e (empty) (no description set)
|
2023-02-20 08:45:23 +00:00
|
|
|
Rebased 1 descendant commits
|
2023-11-20 02:10:39 +00:00
|
|
|
New conflicts appeared in these commits:
|
2024-06-23 22:20:33 +00:00
|
|
|
kkmpptxz d05c4d2a (conflict) (no description set)
|
2023-11-30 07:02:18 +00:00
|
|
|
To resolve the conflicts, start by updating to it:
|
|
|
|
jj new kkmpptxzrspx
|
|
|
|
Then use `jj resolve`, or edit the conflict markers in the file directly.
|
|
|
|
Once the conflicts are resolved, you may want inspect the result with `jj diff`.
|
|
|
|
Then run `jj squash` to move the resolution into the conflicted commit.
|
2024-06-23 22:20:33 +00:00
|
|
|
Working copy now at: kkmpptxz d05c4d2a (conflict) (no description set)
|
|
|
|
Parent commit : rlvkpnrz b9b6011e (empty) (no description set)
|
2023-02-20 08:45:23 +00:00
|
|
|
Added 0 files, modified 1 files, removed 0 files
|
2024-03-28 13:39:55 +00:00
|
|
|
There are unresolved conflicts at these paths:
|
|
|
|
file2 2-sided conflict including 1 deletion
|
2023-02-20 08:45:23 +00:00
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r=@-"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
|
|
|
|
// Can restore this revision from another revision
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "--from", "@--"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created kkmpptxz 1154634b (no description set)
|
|
|
|
Working copy now at: kkmpptxz 1154634b (no description set)
|
|
|
|
Parent commit : rlvkpnrz ef160660 (no description set)
|
2022-03-30 17:38:25 +00:00
|
|
|
Added 1 files, modified 0 files, removed 2 files
|
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s"]);
|
2022-04-28 23:32:18 +00:00
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2024-01-26 06:59:45 +00:00
|
|
|
D file2
|
2022-04-28 23:32:18 +00:00
|
|
|
"###);
|
2022-03-30 17:38:25 +00:00
|
|
|
|
|
|
|
// Can restore into other revision
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "--to", "@-"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created rlvkpnrz ad805965 (no description set)
|
2022-03-30 17:38:25 +00:00
|
|
|
Rebased 1 descendant commits
|
2024-06-23 22:20:33 +00:00
|
|
|
Working copy now at: kkmpptxz 3fcdcbf2 (empty) (no description set)
|
|
|
|
Parent commit : rlvkpnrz ad805965 (no description set)
|
2022-03-30 17:38:25 +00:00
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r", "@-"]);
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2024-01-26 06:59:45 +00:00
|
|
|
D file1
|
2022-03-30 17:38:25 +00:00
|
|
|
A file2
|
|
|
|
A file3
|
|
|
|
"###);
|
|
|
|
|
2022-04-24 19:13:43 +00:00
|
|
|
// Can combine `--from` and `--to`
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
let (stdout, stderr) =
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["restore", "--from", "@", "--to", "@-"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created rlvkpnrz f256040a (no description set)
|
2022-04-24 19:13:43 +00:00
|
|
|
Rebased 1 descendant commits
|
2024-06-23 22:20:33 +00:00
|
|
|
Working copy now at: kkmpptxz 9c6f2083 (empty) (no description set)
|
|
|
|
Parent commit : rlvkpnrz f256040a (no description set)
|
2022-04-24 19:13:43 +00:00
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r", "@-"]);
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2024-01-26 06:59:45 +00:00
|
|
|
D file1
|
2022-04-24 19:13:43 +00:00
|
|
|
A file2
|
|
|
|
A file3
|
|
|
|
"###);
|
|
|
|
|
2022-03-30 17:38:25 +00:00
|
|
|
// Can restore only specified paths
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(&repo_path, &["undo"]);
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "file2", "file3"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-06-23 22:20:33 +00:00
|
|
|
Created kkmpptxz 4ad35a2f (no description set)
|
|
|
|
Working copy now at: kkmpptxz 4ad35a2f (no description set)
|
|
|
|
Parent commit : rlvkpnrz ef160660 (no description set)
|
2022-03-30 17:38:25 +00:00
|
|
|
Added 0 files, modified 1 files, removed 1 files
|
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s"]);
|
2022-04-28 23:32:18 +00:00
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2024-01-26 06:59:45 +00:00
|
|
|
D file1
|
2022-04-28 23:32:18 +00:00
|
|
|
"###);
|
2022-03-30 17:38:25 +00:00
|
|
|
}
|
2023-02-10 05:48:47 +00:00
|
|
|
|
|
|
|
// Much of this test is copied from test_resolve_command
|
|
|
|
#[test]
|
|
|
|
fn test_restore_conflicted_merge() {
|
|
|
|
let test_env = TestEnvironment::default();
|
2024-05-17 19:49:25 +00:00
|
|
|
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
|
2023-02-10 05:48:47 +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###"
|
|
|
|
@ conflict
|
|
|
|
├─╮
|
2023-07-28 06:51:08 +00:00
|
|
|
│ ◉ b
|
|
|
|
◉ │ a
|
2023-02-10 05:48:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ base
|
|
|
|
◉
|
2023-02-10 05:48:47 +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
|
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
|
|
|
"###);
|
2023-02-10 05:48:47 +00:00
|
|
|
|
|
|
|
// Overwrite the file...
|
|
|
|
std::fs::write(repo_path.join("file"), "resolution").unwrap();
|
|
|
|
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff"]),
|
|
|
|
@r###"
|
|
|
|
Resolved conflict in file:
|
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
|
|
|
1 : <<<<<<< Conflict 1 of 1
|
|
|
|
2 : %%%%%%% Changes from base to side #1
|
2023-02-10 05:48:47 +00:00
|
|
|
3 : -base
|
|
|
|
4 : +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
|
|
|
5 : +++++++ Contents of side #2
|
2023-02-10 05:48:47 +00:00
|
|
|
6 : b
|
2024-05-16 01:00:50 +00:00
|
|
|
7 : >>>>>>> Conflict 1 of 1 ends
|
2023-02-10 05:48:47 +00:00
|
|
|
1: resolution
|
|
|
|
"###);
|
|
|
|
|
|
|
|
// ...and restore it back again.
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "file"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-04-21 19:37:19 +00:00
|
|
|
Created vruxwmqv 126facb5 conflict | (conflict) (empty) conflict
|
|
|
|
Working copy now at: vruxwmqv 126facb5 conflict | (conflict) (empty) conflict
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : zsuskuln aa493daf a | a
|
|
|
|
Parent commit : royxmykx db6a4daf b | b
|
2023-02-10 05:48:47 +00:00
|
|
|
Added 0 files, modified 1 files, removed 0 files
|
2024-03-28 13:39:55 +00:00
|
|
|
There are unresolved conflicts at these paths:
|
|
|
|
file 2-sided conflict
|
2023-02-10 05:48:47 +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
|
2023-02-10 05:48:47 +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
|
2023-02-10 05:48:47 +00:00
|
|
|
b
|
2024-05-16 01:00:50 +00:00
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-02-10 05:48:47 +00:00
|
|
|
"###);
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["diff"]);
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
|
|
|
|
// The same, but without the `file` argument. Overwrite the file...
|
|
|
|
std::fs::write(repo_path.join("file"), "resolution").unwrap();
|
|
|
|
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["diff"]),
|
|
|
|
@r###"
|
|
|
|
Resolved conflict in file:
|
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
|
|
|
1 : <<<<<<< Conflict 1 of 1
|
|
|
|
2 : %%%%%%% Changes from base to side #1
|
2023-02-10 05:48:47 +00:00
|
|
|
3 : -base
|
|
|
|
4 : +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
|
|
|
5 : +++++++ Contents of side #2
|
2023-02-10 05:48:47 +00:00
|
|
|
6 : b
|
2024-05-16 01:00:50 +00:00
|
|
|
7 : >>>>>>> Conflict 1 of 1 ends
|
2023-02-10 05:48:47 +00:00
|
|
|
1: resolution
|
|
|
|
"###);
|
|
|
|
|
|
|
|
// ... and restore it back again.
|
2023-10-10 11:59:18 +00:00
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore"]);
|
2023-10-10 11:07:06 +00:00
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-04-21 19:37:19 +00:00
|
|
|
Created vruxwmqv b553ebcf conflict | (conflict) (empty) conflict
|
|
|
|
Working copy now at: vruxwmqv b553ebcf conflict | (conflict) (empty) conflict
|
2023-08-08 03:11:59 +00:00
|
|
|
Parent commit : zsuskuln aa493daf a | a
|
|
|
|
Parent commit : royxmykx db6a4daf b | b
|
2023-02-10 05:48:47 +00:00
|
|
|
Added 0 files, modified 1 files, removed 0 files
|
2024-03-28 13:39:55 +00:00
|
|
|
There are unresolved conflicts at these paths:
|
|
|
|
file 2-sided conflict
|
2023-02-10 05:48:47 +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
|
2023-02-10 05:48:47 +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
|
2023-02-10 05:48:47 +00:00
|
|
|
b
|
2024-05-16 01:00:50 +00:00
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-02-10 05:48:47 +00:00
|
|
|
"###);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn create_commit(
|
|
|
|
test_env: &TestEnvironment,
|
|
|
|
repo_path: &Path,
|
|
|
|
name: &str,
|
|
|
|
parents: &[&str],
|
|
|
|
files: &[(&str, &str)],
|
|
|
|
) {
|
|
|
|
if parents.is_empty() {
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(repo_path, &["new", "root()", "-m", name]);
|
2023-02-10 05:48:47 +00:00
|
|
|
} else {
|
|
|
|
let mut args = vec!["new", "-m", name];
|
|
|
|
args.extend(parents);
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(repo_path, &args);
|
2023-02-10 05:48:47 +00:00
|
|
|
}
|
|
|
|
for (name, content) in files {
|
|
|
|
std::fs::write(repo_path.join(name), content).unwrap();
|
|
|
|
}
|
2023-10-10 11:59:18 +00:00
|
|
|
test_env.jj_cmd_ok(repo_path, &["branch", "create", name]);
|
2023-02-10 05:48:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", "branches"])
|
|
|
|
}
|