2023-01-16 19:22:10 +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;
|
|
|
|
|
|
|
|
|
|
pub mod common;
|
|
|
|
|
|
|
|
|
|
fn create_commit(test_env: &TestEnvironment, repo_path: &Path, name: &str, parents: &[&str]) {
|
|
|
|
|
if parents.is_empty() {
|
|
|
|
|
test_env.jj_cmd_success(repo_path, &["new", "root", "-m", name]);
|
|
|
|
|
} else {
|
|
|
|
|
let mut args = vec!["new", "-m", name];
|
|
|
|
|
args.extend(parents);
|
|
|
|
|
test_env.jj_cmd_success(repo_path, &args);
|
|
|
|
|
}
|
|
|
|
|
std::fs::write(repo_path.join(name), format!("{name}\n")).unwrap();
|
|
|
|
|
test_env.jj_cmd_success(repo_path, &["branch", "create", name]);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-15 05:59:31 +00:00
|
|
|
#[test]
|
|
|
|
|
fn test_duplicate() {
|
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
|
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
|
|
create_commit(&test_env, &repo_path, "a", &[]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "b", &[]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "c", &["a", "b"]);
|
|
|
|
|
// Test the setup
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 17a00fc21654 c
|
|
|
|
|
├─╮
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ 2443ea76b0b1 a
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
◉ │ d370aee184ba b
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-15 05:59:31 +00:00
|
|
|
"###);
|
|
|
|
|
|
2023-01-15 06:35:56 +00:00
|
|
|
let stderr = test_env.jj_cmd_failure(&repo_path, &["duplicate", "root"]);
|
|
|
|
|
insta::assert_snapshot!(stderr, @r###"
|
|
|
|
|
Error: Cannot rewrite the root commit
|
|
|
|
|
"###);
|
2023-01-15 05:59:31 +00:00
|
|
|
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "a"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-01-10 06:54:10 +00:00
|
|
|
Duplicated 2443ea76b0b1 as 2f6dc5a1ffc2 a
|
2023-01-15 05:59:31 +00:00
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2f6dc5a1ffc2 a
|
2023-02-09 02:53:47 +00:00
|
|
|
│ @ 17a00fc21654 c
|
|
|
|
|
│ ├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ ◉ 2443ea76b0b1 a
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ d370aee184ba b
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-15 05:59:31 +00:00
|
|
|
"###);
|
|
|
|
|
|
2023-01-15 06:35:56 +00:00
|
|
|
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["undo"]), @"");
|
2023-01-15 05:59:31 +00:00
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate" /* duplicates `c` */]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-01-10 06:54:10 +00:00
|
|
|
Duplicated 17a00fc21654 as 1dd099ea963c c
|
2023-01-15 05:59:31 +00:00
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 1dd099ea963c c
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
|
|
|
|
│ │ @ 17a00fc21654 c
|
|
|
|
|
╭─┬─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ 2443ea76b0b1 a
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
◉ │ d370aee184ba b
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-15 05:59:31 +00:00
|
|
|
"###);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-10 06:54:10 +00:00
|
|
|
#[test]
|
|
|
|
|
fn test_duplicate_many() {
|
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
|
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
|
|
create_commit(&test_env, &repo_path, "a", &[]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "b", &["a"]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "c", &["a"]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "d", &["c"]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "e", &["b", "d"]);
|
|
|
|
|
// Test the setup
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 921dde6e55c0 e
|
|
|
|
|
├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ 1394f625cbbd b
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ ebd06dba20ec d
|
|
|
|
|
◉ │ c0cb3a0b73e7 c
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "b:"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Duplicated 1394f625cbbd as 3b74d9691015 b
|
|
|
|
|
Duplicated 921dde6e55c0 as 8348ddcec733 e
|
|
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 8348ddcec733 e
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ 3b74d9691015 b
|
2023-02-09 02:53:47 +00:00
|
|
|
│ │ @ 921dde6e55c0 e
|
|
|
|
|
│ ╭─┤
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ ◉ 1394f625cbbd b
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ ebd06dba20ec d
|
|
|
|
|
│ ◉ c0cb3a0b73e7 c
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// Try specifying the same commit twice directly
|
|
|
|
|
test_env.jj_cmd_success(&repo_path, &["undo"]);
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "b", "b"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Duplicated 1394f625cbbd as 0276d3d7c24d b
|
|
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0276d3d7c24d b
|
2023-02-09 02:53:47 +00:00
|
|
|
│ @ 921dde6e55c0 e
|
|
|
|
|
│ ├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ ◉ 1394f625cbbd b
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ ebd06dba20ec d
|
|
|
|
|
│ ◉ c0cb3a0b73e7 c
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// Try specifying the same commit twice indirectly
|
|
|
|
|
test_env.jj_cmd_success(&repo_path, &["undo"]);
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "b:", "d:"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Duplicated 1394f625cbbd as fa167d18a83a b
|
|
|
|
|
Duplicated ebd06dba20ec as 2181781b4f81 d
|
|
|
|
|
Duplicated 921dde6e55c0 as 0f7430f2727a e
|
|
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0f7430f2727a e
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ fa167d18a83a b
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
◉ │ 2181781b4f81 d
|
2023-02-09 02:53:47 +00:00
|
|
|
│ │ @ 921dde6e55c0 e
|
|
|
|
|
│ │ ├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ │ ◉ 1394f625cbbd b
|
|
|
|
|
│ ├───╯
|
|
|
|
|
│ │ ◉ ebd06dba20ec d
|
|
|
|
|
├───╯
|
|
|
|
|
◉ │ c0cb3a0b73e7 c
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
test_env.jj_cmd_success(&repo_path, &["undo"]);
|
|
|
|
|
// Reminder of the setup
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 921dde6e55c0 e
|
|
|
|
|
├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ 1394f625cbbd b
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ ebd06dba20ec d
|
|
|
|
|
◉ │ c0cb3a0b73e7 c
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "d:", "a"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Duplicated 2443ea76b0b1 as c6f7f8c4512e a
|
|
|
|
|
Duplicated ebd06dba20ec as d94e4c55a68b d
|
|
|
|
|
Duplicated 921dde6e55c0 as 9bd4389f5d47 e
|
|
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 9bd4389f5d47 e
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ d94e4c55a68b d
|
2023-07-22 18:14:03 +00:00
|
|
|
│ │ @ 921dde6e55c0 e
|
|
|
|
|
│ ╭─┤
|
|
|
|
|
│ ◉ │ 1394f625cbbd b
|
|
|
|
|
│ │ ◉ ebd06dba20ec d
|
2023-02-09 02:53:47 +00:00
|
|
|
├───╯
|
2023-07-22 18:14:03 +00:00
|
|
|
◉ │ c0cb3a0b73e7 c
|
|
|
|
|
├─╯
|
|
|
|
|
◉ 2443ea76b0b1 a
|
|
|
|
|
│ ◉ c6f7f8c4512e a
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
// Check for BUG -- makes too many 'a'-s, etc.
|
|
|
|
|
test_env.jj_cmd_success(&repo_path, &["undo"]);
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "a:"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Duplicated 2443ea76b0b1 as 0fe67a05989e a
|
|
|
|
|
Duplicated 1394f625cbbd as e13ac0adabdf b
|
|
|
|
|
Duplicated c0cb3a0b73e7 as df53fa589286 c
|
|
|
|
|
Duplicated ebd06dba20ec as 2f2442db08eb d
|
|
|
|
|
Duplicated 921dde6e55c0 as ee8fe64ed254 e
|
|
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ ee8fe64ed254 e
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ ◉ e13ac0adabdf b
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ │ 2f2442db08eb d
|
|
|
|
|
◉ │ df53fa589286 c
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 0fe67a05989e a
|
2023-02-09 02:53:47 +00:00
|
|
|
│ @ 921dde6e55c0 e
|
|
|
|
|
│ ├─╮
|
revset_graph: group commits topologically
The original idea was similar to Mercurial's "topo" sorting, but it was bad
at handling merge-heavy history. In order to render merges of topic branches
nicely, we need to prioritize branches at merge point, not at fork point.
OTOH, we do also want to place unmerged branches as close to the fork point
as possible. This commit implements the former requirement, and the latter
will be addressed by the next commit.
I think this is similar to Git's sorting logic described in the following blog
post. In our case, the in-degree walk can be dumb since topological order is
guaranteed by the index. We keep HashSet<CommitId> instead of an in-degree
integer value, which will be used in the next commit to resolve new heads as
late as possible.
https://github.blog/2022-08-30-gits-database-internals-ii-commit-history-queries/#topological-sorting
Compared to Sapling's beautify_graph(), this is lazy, and can roughly preserve
the index (or chronological) order. I tried beautify_graph() with prioritizing
the @ commit, but the result seemed too aggressively reordered. Perhaps, for
more complex history, beautify_graph() would produce a better result. For my
wip branches (~30 branches, a couple of commits per branch), this works pretty
well.
#242
2023-07-16 10:47:46 +00:00
|
|
|
│ │ ◉ 1394f625cbbd b
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ │ ebd06dba20ec d
|
|
|
|
|
│ ◉ │ c0cb3a0b73e7 c
|
2023-02-09 02:53:47 +00:00
|
|
|
│ ├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
│ ◉ 2443ea76b0b1 a
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-10 06:54:10 +00:00
|
|
|
"###);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-16 19:22:10 +00:00
|
|
|
// https://github.com/martinvonz/jj/issues/1050
|
|
|
|
|
#[test]
|
|
|
|
|
fn test_undo_after_duplicate() {
|
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
|
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
|
|
create_commit(&test_env, &repo_path, "a", &[]);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 2443ea76b0b1 a
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-16 19:22:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "a"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-01-10 06:54:10 +00:00
|
|
|
Duplicated 2443ea76b0b1 as f5cefcbb65a4 a
|
2023-01-16 19:22:10 +00:00
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ f5cefcbb65a4 a
|
2023-02-09 02:53:47 +00:00
|
|
|
│ @ 2443ea76b0b1 a
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-16 19:22:10 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
insta::assert_snapshot!(test_env.jj_cmd_success(&repo_path, &["undo"]), @"");
|
|
|
|
|
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 2443ea76b0b1 a
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 000000000000
|
2023-01-16 19:22:10 +00:00
|
|
|
"###);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-15 06:08:13 +00:00
|
|
|
// https://github.com/martinvonz/jj/issues/694
|
|
|
|
|
#[test]
|
|
|
|
|
fn test_rebase_duplicates() {
|
|
|
|
|
let test_env = TestEnvironment::default();
|
|
|
|
|
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
|
|
|
|
|
let repo_path = test_env.env_root().join("repo");
|
|
|
|
|
|
|
|
|
|
create_commit(&test_env, &repo_path, "a", &[]);
|
|
|
|
|
create_commit(&test_env, &repo_path, "b", &["a"]);
|
|
|
|
|
// Test the setup
|
|
|
|
|
insta::assert_snapshot!(get_log_output_with_ts(&test_env, &repo_path), @r###"
|
2023-02-09 02:53:47 +00:00
|
|
|
@ 1394f625cbbd b @ 2001-02-03 04:05:11.000 +07:00
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a @ 2001-02-03 04:05:09.000 +07:00
|
|
|
|
|
◉ 000000000000 @ 1970-01-01 00:00:00.000 +00:00
|
2023-01-15 06:08:13 +00:00
|
|
|
"###);
|
|
|
|
|
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "b"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-01-10 06:54:10 +00:00
|
|
|
Duplicated 1394f625cbbd as fdaaf3950f07 b
|
2023-01-15 06:08:13 +00:00
|
|
|
"###);
|
|
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["duplicate", "b"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
2023-01-10 06:54:10 +00:00
|
|
|
Duplicated 1394f625cbbd as 870cf438ccbb b
|
2023-01-15 06:08:13 +00:00
|
|
|
"###);
|
|
|
|
|
insta::assert_snapshot!(get_log_output_with_ts(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 870cf438ccbb b @ 2001-02-03 04:05:14.000 +07:00
|
|
|
|
|
│ ◉ fdaaf3950f07 b @ 2001-02-03 04:05:13.000 +07:00
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
|
|
|
|
│ @ 1394f625cbbd b @ 2001-02-03 04:05:11.000 +07:00
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2443ea76b0b1 a @ 2001-02-03 04:05:09.000 +07:00
|
|
|
|
|
◉ 000000000000 @ 1970-01-01 00:00:00.000 +00:00
|
2023-01-15 06:08:13 +00:00
|
|
|
"###);
|
|
|
|
|
|
2023-01-15 07:28:36 +00:00
|
|
|
let stdout = test_env.jj_cmd_success(&repo_path, &["rebase", "-s", "a", "-d", "a-"]);
|
|
|
|
|
insta::assert_snapshot!(stdout, @r###"
|
|
|
|
|
Rebased 4 commits
|
|
|
|
|
Working copy now at: 29bd36b60e60 b
|
2023-04-29 05:01:31 +00:00
|
|
|
Parent commit : 2f6dc5a1ffc2 a
|
2023-01-15 07:28:36 +00:00
|
|
|
"###);
|
|
|
|
|
// Some of the duplicate commits' timestamps were changed a little to make them
|
|
|
|
|
// have distinct commit ids.
|
|
|
|
|
insta::assert_snapshot!(get_log_output_with_ts(&test_env, &repo_path), @r###"
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ b43fe7354758 b @ 2001-02-03 04:05:14.000 +07:00
|
|
|
|
|
│ ◉ 08beb14c3ead b @ 2001-02-03 04:05:15.000 +07:00
|
2023-02-09 02:53:47 +00:00
|
|
|
├─╯
|
|
|
|
|
│ @ 29bd36b60e60 b @ 2001-02-03 04:05:16.000 +07:00
|
|
|
|
|
├─╯
|
2023-03-15 03:37:56 +00:00
|
|
|
◉ 2f6dc5a1ffc2 a @ 2001-02-03 04:05:16.000 +07:00
|
|
|
|
|
◉ 000000000000 @ 1970-01-01 00:00:00.000 +00:00
|
2023-01-15 06:08:13 +00:00
|
|
|
"###);
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-16 19:22:10 +00:00
|
|
|
fn get_log_output(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
2023-02-28 11:30:57 +00:00
|
|
|
let template = r#"commit_id.short() ++ " " ++ description.first_line()"#;
|
2023-02-28 10:43:14 +00:00
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", template])
|
2023-01-16 19:22:10 +00:00
|
|
|
}
|
2023-01-15 06:08:13 +00:00
|
|
|
|
|
|
|
|
fn get_log_output_with_ts(test_env: &TestEnvironment, repo_path: &Path) -> String {
|
2023-02-28 11:30:57 +00:00
|
|
|
let template = r###"
|
|
|
|
|
commit_id.short() ++ " " ++ description.first_line() ++ " @ " ++ committer.timestamp()
|
|
|
|
|
"###;
|
2023-02-28 10:43:14 +00:00
|
|
|
test_env.jj_cmd_success(repo_path, &["log", "-T", template])
|
2023-01-15 06:08:13 +00:00
|
|
|
}
|
