2023-06-12 19:51:56 +00:00
|
|
|
|
// Copyright 2023 The Jujutsu Authors
|
|
|
|
|
//
|
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
|
//
|
|
|
|
|
// https://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
//
|
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
|
|
use std::path::Path;
|
|
|
|
|
|
|
|
|
|
use crate::common::TestEnvironment;
|
|
|
|
|
|
|
|
|
|
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-06-12 19:51:56 +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-06-12 19:51:56 +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-06-12 19:51:56 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
|
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", "branches"])
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn test_chmod_regular_conflict() {
|
|
|
|
|
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-06-12 19:51: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, "n", &["base"], &[("file", "n\n")]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "x", &["base"], &[("file", "x\n")]);
|
|
|
|
|
// Test chmodding a file. The effect will be visible in the conflict below.
|
2024-06-14 14:34:17 +00:00
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["file", "chmod", "x", "file", "-r=x"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
create_commit(&test_env, &repo_path, "conflict", &["x", "n"], &[]);
|
|
|
|
|
|
|
|
|
|
// Test the setup
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
|
|
|
|
@ conflict
|
|
|
|
|
├─╮
|
2024-07-15 22:20:10 +00:00
|
|
|
|
│ ○ n
|
|
|
|
|
○ │ x
|
2023-06-12 19:51:56 +00:00
|
|
|
|
├─╯
|
2024-07-15 22:20:10 +00:00
|
|
|
|
○ base
|
|
|
|
|
◆
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("587be6b4c3f93f93c489c0111bba5596147a26cb"), executable: true }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("8ba3a16384aacc37d01564b28401755ce8053f51"), executable: false })]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@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-10-24 03:01:00 +00:00
|
|
|
|
-base
|
|
|
|
|
+x
|
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-10-24 03:01:00 +00:00
|
|
|
|
n
|
2024-05-16 01:00:50 +00:00
|
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// Test chmodding a conflict
|
2024-06-14 14:34:17 +00:00
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["file", "chmod", "x", "file"]);
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("587be6b4c3f93f93c489c0111bba5596147a26cb"), executable: true }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: true }), Some(File { id: FileId("8ba3a16384aacc37d01564b28401755ce8053f51"), executable: true })]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@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-10-24 03:01:00 +00:00
|
|
|
|
-base
|
|
|
|
|
+x
|
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-10-24 03:01:00 +00:00
|
|
|
|
n
|
2024-05-16 01:00:50 +00:00
|
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
2024-06-14 14:34:17 +00:00
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["file", "chmod", "n", "file"]);
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("587be6b4c3f93f93c489c0111bba5596147a26cb"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(File { id: FileId("8ba3a16384aacc37d01564b28401755ce8053f51"), executable: false })]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@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-06-12 19:51:56 +00:00
|
|
|
|
-base
|
|
|
|
|
+x
|
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-06-12 19:51:56 +00:00
|
|
|
|
n
|
2024-05-16 01:00:50 +00:00
|
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
|
2024-04-09 03:33:32 +00:00
|
|
|
|
// Unmatched paths should generate warnings
|
2024-06-14 14:34:17 +00:00
|
|
|
|
let (_stdout, stderr) =
|
|
|
|
|
test_env.jj_cmd_ok(&repo_path, &["file", "chmod", "x", "nonexistent", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2024-04-09 03:33:32 +00:00
|
|
|
|
Warning: No matching entries for paths: nonexistent
|
2024-04-21 19:37:19 +00:00
|
|
|
|
Working copy now at: yostqsxw e5912d62 conflict | (conflict) conflict
|
2024-04-09 03:33:32 +00:00
|
|
|
|
Parent commit : royxmykx 427fbd2f x | x
|
|
|
|
|
Parent commit : zsuskuln 3f83a26d n | n
|
|
|
|
|
Added 0 files, modified 1 files, removed 0 files
|
|
|
|
|
There are unresolved conflicts at these paths:
|
|
|
|
|
file 2-sided conflict including an executable
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO: Test demonstrating that conflicts whose *base* is not a file are
|
|
|
|
|
// chmod-dable
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn test_chmod_file_dir_deletion_conflicts() {
|
|
|
|
|
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-06-12 19:51: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, "file", &["base"], &[("file", "a\n")]);
|
|
|
|
|
|
|
|
|
|
create_commit(&test_env, &repo_path, "deletion", &["base"], &[]);
|
|
|
|
|
std::fs::remove_file(repo_path.join("file")).unwrap();
|
|
|
|
|
|
|
|
|
|
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 a file-dir conflict and a file-deletion conflict
|
|
|
|
|
create_commit(&test_env, &repo_path, "file_dir", &["file", "dir"], &[]);
|
|
|
|
|
create_commit(
|
|
|
|
|
&test_env,
|
|
|
|
|
&repo_path,
|
|
|
|
|
"file_deletion",
|
|
|
|
|
&["file", "deletion"],
|
|
|
|
|
&[],
|
|
|
|
|
);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
|
|
|
|
@ file_deletion
|
|
|
|
|
├─╮
|
2024-07-15 22:20:10 +00:00
|
|
|
|
│ ○ deletion
|
|
|
|
|
│ │ × file_dir
|
2023-07-28 06:51:08 +00:00
|
|
|
|
╭───┤
|
2024-07-15 22:20:10 +00:00
|
|
|
|
│ │ ○ dir
|
2023-07-28 06:51:08 +00:00
|
|
|
|
│ ├─╯
|
2024-07-15 22:20:10 +00:00
|
|
|
|
○ │ file
|
2023-07-28 06:51:08 +00:00
|
|
|
|
├─╯
|
2024-07-15 22:20:10 +00:00
|
|
|
|
○ base
|
|
|
|
|
◆
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// The file-dir conflict cannot be chmod-ed
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree", "-r=file_dir"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("78981922613b2afb6025042ff6bd878ac1994e85"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), Some(Tree(TreeId("133bb38fc4e4bf6b551f1f04db7e48f04cac2877")))]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "-r=file_dir", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
|
|
|
|
Conflict:
|
|
|
|
|
Removing file with id df967b96a579e45a18b8251732d16804b2e56a55
|
|
|
|
|
Adding file with id 78981922613b2afb6025042ff6bd878ac1994e85
|
|
|
|
|
Adding tree with id 133bb38fc4e4bf6b551f1f04db7e48f04cac2877
|
|
|
|
|
"###);
|
2024-06-14 14:34:17 +00:00
|
|
|
|
let stderr =
|
|
|
|
|
test_env.jj_cmd_failure(&repo_path, &["file", "chmod", "x", "file", "-r=file_dir"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-08-14 06:28:59 +00:00
|
|
|
|
Error: Some of the sides of the conflict are not files at 'file'.
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// The file_deletion conflict can be chmod-ed
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree", "-r=file_deletion"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("78981922613b2afb6025042ff6bd878ac1994e85"), executable: false }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: false }), None]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "-r=file_deletion", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@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
|
2023-06-12 19:51:56 +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
|
2023-06-12 19:51:56 +00:00
|
|
|
|
-base
|
2024-05-16 01:00:50 +00:00
|
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
2024-06-14 14:34:17 +00:00
|
|
|
|
let (stdout, stderr) = test_env.jj_cmd_ok(
|
|
|
|
|
&repo_path,
|
|
|
|
|
&["file", "chmod", "x", "file", "-r=file_deletion"],
|
|
|
|
|
);
|
2023-10-10 11:07:06 +00:00
|
|
|
|
insta::assert_snapshot!(stdout, @"");
|
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
2023-11-20 02:10:39 +00:00
|
|
|
|
New conflicts appeared in these commits:
|
2024-04-21 19:37:19 +00:00
|
|
|
|
kmkuslsw 1b2ef84c file_deletion | (conflict) file_deletion
|
2023-11-30 07:02:18 +00:00
|
|
|
|
To resolve the conflicts, start by updating to it:
|
|
|
|
|
jj new kmkuslswpqwq
|
|
|
|
|
Then use `jj resolve`, or edit the conflict markers in the file directly.
|
2024-07-16 17:30:40 +00:00
|
|
|
|
Once the conflicts are resolved, you may want to inspect the result with `jj diff`.
|
2023-11-30 07:02:18 +00:00
|
|
|
|
Then run `jj squash` to move the resolution into the conflicted commit.
|
2024-04-21 19:37:19 +00:00
|
|
|
|
Working copy now at: kmkuslsw 1b2ef84c file_deletion | (conflict) file_deletion
|
2023-08-08 03:11:59 +00:00
|
|
|
|
Parent commit : zsuskuln c51c9c55 file | file
|
|
|
|
|
Parent commit : royxmykx 6b18b3c1 deletion | deletion
|
2023-06-12 19:51:56 +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 including 1 deletion and an executable
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
2023-10-24 04:47:19 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["debug", "tree", "-r=file_deletion"]);
|
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@r###"
|
2024-03-19 20:18:54 +00:00
|
|
|
|
file: Ok(Conflicted([Some(File { id: FileId("78981922613b2afb6025042ff6bd878ac1994e85"), executable: true }), Some(File { id: FileId("df967b96a579e45a18b8251732d16804b2e56a55"), executable: true }), None]))
|
2023-10-24 04:47:19 +00:00
|
|
|
|
"###);
|
2024-06-26 01:17:11 +00:00
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["file", "show", "-r=file_deletion", "file"]);
|
2023-06-12 19:51:56 +00:00
|
|
|
|
insta::assert_snapshot!(stdout,
|
|
|
|
|
@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
|
2023-10-24 03:01:00 +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
|
2023-10-24 03:01:00 +00:00
|
|
|
|
-base
|
2024-05-16 01:00:50 +00:00
|
|
|
|
>>>>>>> Conflict 1 of 1 ends
|
2023-06-12 19:51:56 +00:00
|
|
|
|
"###);
|
|
|
|
|
}
|