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###"
|
2023-07-11 01:46:38 +00:00
|
|
|
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, @"");
|
|
|
|
|
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###"
|
2023-07-11 01:46:38 +00:00
|
|
|
Created rlvkpnrz e25100af (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-04-21 19:37:19 +00:00
|
|
|
kkmpptxz 4906178a (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-04-21 19:37:19 +00:00
|
|
|
Working copy now at: kkmpptxz 4906178a (conflict) (no description set)
|
2023-07-11 01:46:38 +00:00
|
|
|
Parent commit : rlvkpnrz e25100af (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###"
|
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)
|
2023-07-11 01:46:38 +00:00
|
|
|
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"]);
|
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###"
|
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###"
|
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###"
|
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)
|
2022-04-24 19:13:43 +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 525afd5d (empty) (no description set)
|
|
|
|
Parent commit : rlvkpnrz 5f6eb3d5 (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###"
|
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)
|
2023-07-11 01:46:38 +00:00
|
|
|
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"]);
|
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"])
|
|
|
|
}
|