jj/cli/tests/test_restore_command.rs

287 lines
11 KiB
Rust
Raw Normal View History

// 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.
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();
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();
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();
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();
// 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
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
Created kkmpptxz ed1678e3 (empty) (no description set)
Working copy now at: kkmpptxz ed1678e3 (empty) (no description set)
Parent commit : rlvkpnrz 1a986a27 (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, @"");
// Can restore another revision from its parents
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r=@-"]);
insta::assert_snapshot!(stdout, @r###"
A file2
"###);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "-c=@-"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
Created rlvkpnrz e25100af (empty) (no description set)
Rebased 1 descendant commits
New conflicts appeared in these commits:
kkmpptxz 4906178a (conflict) (no description set)
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.
Working copy now at: kkmpptxz 4906178a (conflict) (no description set)
Parent commit : rlvkpnrz e25100af (empty) (no description set)
Added 0 files, modified 1 files, removed 0 files
There are unresolved conflicts at these paths:
file2 2-sided conflict including 1 deletion
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["diff", "-s", "-r=@-"]);
insta::assert_snapshot!(stdout, @"");
// Can restore this revision from another revision
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "--from", "@--"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Created kkmpptxz 1dd6eb63 (no description set)
Working copy now at: kkmpptxz 1dd6eb63 (no description set)
Parent commit : rlvkpnrz 1a986a27 (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"]);
insta::assert_snapshot!(stdout, @r###"
D file2
"###);
2022-03-30 17:38:25 +00:00
// Can restore into other revision
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "--to", "@-"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Created rlvkpnrz ec9d5b59 (no description set)
2022-03-30 17:38:25 +00:00
Rebased 1 descendant commits
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Working copy now at: kkmpptxz d6f3c681 (empty) (no description set)
Parent commit : rlvkpnrz ec9d5b59 (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###"
D file1
2022-03-30 17:38:25 +00:00
A file2
A file3
"###);
// Can combine `--from` and `--to`
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let (stdout, stderr) =
test_env.jj_cmd_ok(&repo_path, &["restore", "--from", "@", "--to", "@-"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Created rlvkpnrz 5f6eb3d5 (no description set)
Rebased 1 descendant commits
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Working copy now at: kkmpptxz 525afd5d (empty) (no description set)
Parent commit : rlvkpnrz 5f6eb3d5 (no description set)
"###);
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###"
D file1
A file2
A file3
"###);
2022-03-30 17:38:25 +00:00
// Can restore only specified paths
test_env.jj_cmd_ok(&repo_path, &["undo"]);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "file2", "file3"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
Created kkmpptxz 569ce73d (no description set)
Working copy now at: kkmpptxz 569ce73d (no description set)
Parent commit : rlvkpnrz 1a986a27 (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"]);
insta::assert_snapshot!(stdout, @r###"
D file1
"###);
2022-03-30 17:38:25 +00:00
}
// Much of this test is copied from test_resolve_command
#[test]
fn test_restore_conflicted_merge() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
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
b
a
base
"###);
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
>>>>>>> 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
"###);
// 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
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
6 : b
7 : >>>>>>> Conflict 1 of 1 ends
1: resolution
"###);
// ...and restore it back again.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore", "file"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
Created vruxwmqv 126facb5 conflict | (conflict) (empty) conflict
Working copy now at: vruxwmqv 126facb5 conflict | (conflict) (empty) 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
"###);
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
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
>>>>>>> Conflict 1 of 1 ends
"###);
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
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
6 : b
7 : >>>>>>> Conflict 1 of 1 ends
1: resolution
"###);
// ... and restore it back again.
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["restore"]);
insta::assert_snapshot!(stdout, @"");
insta::assert_snapshot!(stderr, @r###"
Created vruxwmqv b553ebcf conflict | (conflict) (empty) conflict
Working copy now at: vruxwmqv b553ebcf conflict | (conflict) (empty) 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
"###);
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
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
>>>>>>> Conflict 1 of 1 ends
"###);
}
fn create_commit(
test_env: &TestEnvironment,
repo_path: &Path,
name: &str,
parents: &[&str],
files: &[(&str, &str)],
) {
if parents.is_empty() {
test_env.jj_cmd_ok(repo_path, &["new", "root()", "-m", name]);
} else {
let mut args = vec!["new", "-m", name];
args.extend(parents);
test_env.jj_cmd_ok(repo_path, &args);
}
for (name, content) in files {
std::fs::write(repo_path.join(name), content).unwrap();
}
test_env.jj_cmd_ok(repo_path, &["branch", "create", name]);
}
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
test_env.jj_cmd_success(repo_path, &["log", "-T", "branches"])
}