2022-11-26 23:57:50 +00:00
|
|
|
// Copyright 2020 The Jujutsu Authors
|
2020-12-12 08:00:42 +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.
|
|
|
|
|
2022-03-17 03:58:04 +00:00
|
|
|
use std::sync::Arc;
|
|
|
|
|
2023-07-15 15:54:50 +00:00
|
|
|
use jj_lib::op_store::{BranchTarget, RefTarget, WorkspaceId};
|
2023-06-28 14:12:40 +00:00
|
|
|
use jj_lib::repo::{ReadonlyRepo, Repo};
|
|
|
|
use jj_lib::settings::UserSettings;
|
|
|
|
use jj_lib::transaction::Transaction;
|
2021-08-02 04:47:34 +00:00
|
|
|
use maplit::{btreemap, hashset};
|
2020-12-12 08:00:42 +00:00
|
|
|
use test_case::test_case;
|
2022-12-24 15:38:20 +00:00
|
|
|
use testutils::{create_random_commit, write_random_commit, CommitGraphBuilder, TestRepo};
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-09-12 06:52:38 +00:00
|
|
|
#[test_case(false ; "local backend")]
|
|
|
|
#[test_case(true ; "git backend")]
|
2020-12-12 08:00:42 +00:00
|
|
|
fn test_heads_empty(use_git: bool) {
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(use_git);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-11-17 20:29:08 +00:00
|
|
|
assert_eq!(
|
|
|
|
*repo.view().heads(),
|
2022-02-05 21:29:55 +00:00
|
|
|
hashset! {repo.store().root_commit_id().clone()}
|
2021-11-17 20:29:08 +00:00
|
|
|
);
|
2021-04-19 05:52:31 +00:00
|
|
|
assert_eq!(
|
|
|
|
*repo.view().public_heads(),
|
|
|
|
hashset! {repo.store().root_commit_id().clone()}
|
|
|
|
);
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
|
2021-09-12 06:52:38 +00:00
|
|
|
#[test_case(false ; "local backend")]
|
|
|
|
#[test_case(true ; "git backend")]
|
2020-12-12 08:00:42 +00:00
|
|
|
fn test_heads_fork(use_git: bool) {
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(use_git);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-05-01 04:41:27 +00:00
|
|
|
let mut graph_builder = CommitGraphBuilder::new(&settings, tx.mut_repo());
|
|
|
|
let initial = graph_builder.initial_commit();
|
|
|
|
let child1 = graph_builder.commit_with_parents(&[&initial]);
|
|
|
|
let child2 = graph_builder.commit_with_parents(&[&initial]);
|
2021-07-30 21:35:08 +00:00
|
|
|
let repo = tx.commit();
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-01-16 20:15:06 +00:00
|
|
|
assert_eq!(
|
2021-07-30 21:35:08 +00:00
|
|
|
*repo.view().heads(),
|
2021-01-16 20:15:06 +00:00
|
|
|
hashset! {
|
|
|
|
child1.id().clone(),
|
|
|
|
child2.id().clone(),
|
|
|
|
}
|
|
|
|
);
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
|
2021-09-12 06:52:38 +00:00
|
|
|
#[test_case(false ; "local backend")]
|
|
|
|
#[test_case(true ; "git backend")]
|
2020-12-12 08:00:42 +00:00
|
|
|
fn test_heads_merge(use_git: bool) {
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(use_git);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-05-01 04:41:27 +00:00
|
|
|
let mut graph_builder = CommitGraphBuilder::new(&settings, tx.mut_repo());
|
|
|
|
let initial = graph_builder.initial_commit();
|
|
|
|
let child1 = graph_builder.commit_with_parents(&[&initial]);
|
|
|
|
let child2 = graph_builder.commit_with_parents(&[&initial]);
|
|
|
|
let merge = graph_builder.commit_with_parents(&[&child1, &child2]);
|
2021-07-30 21:35:08 +00:00
|
|
|
let repo = tx.commit();
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2022-02-05 21:29:55 +00:00
|
|
|
assert_eq!(*repo.view().heads(), hashset! {merge.id().clone()});
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
2021-08-02 04:47:34 +00:00
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_merge_views_heads() {
|
|
|
|
// Tests merging of the view's heads (by performing concurrent operations).
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2021-08-02 04:47:34 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
2021-08-02 04:47:34 +00:00
|
|
|
let mut_repo = tx.mut_repo();
|
2022-12-24 15:38:20 +00:00
|
|
|
let head_unchanged = write_random_commit(mut_repo, &settings);
|
|
|
|
let head_remove_tx1 = write_random_commit(mut_repo, &settings);
|
|
|
|
let head_remove_tx2 = write_random_commit(mut_repo, &settings);
|
|
|
|
let public_head_unchanged = write_random_commit(mut_repo, &settings);
|
2021-08-02 04:47:34 +00:00
|
|
|
mut_repo.add_public_head(&public_head_unchanged);
|
2022-12-24 15:38:20 +00:00
|
|
|
let public_head_remove_tx1 = write_random_commit(mut_repo, &settings);
|
2021-08-02 04:47:34 +00:00
|
|
|
mut_repo.add_public_head(&public_head_remove_tx1);
|
2022-12-24 15:38:20 +00:00
|
|
|
let public_head_remove_tx2 = write_random_commit(mut_repo, &settings);
|
2021-08-02 04:47:34 +00:00
|
|
|
mut_repo.add_public_head(&public_head_remove_tx2);
|
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2021-09-25 16:25:42 +00:00
|
|
|
tx1.mut_repo().remove_head(head_remove_tx1.id());
|
|
|
|
tx1.mut_repo()
|
|
|
|
.remove_public_head(public_head_remove_tx1.id());
|
2022-12-24 15:38:20 +00:00
|
|
|
let head_add_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
|
|
|
let public_head_add_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
2021-08-02 04:47:34 +00:00
|
|
|
tx1.mut_repo().add_public_head(&public_head_add_tx1);
|
|
|
|
tx1.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2021-09-25 16:25:42 +00:00
|
|
|
tx2.mut_repo().remove_head(head_remove_tx2.id());
|
|
|
|
tx2.mut_repo()
|
|
|
|
.remove_public_head(public_head_remove_tx2.id());
|
2022-12-24 15:38:20 +00:00
|
|
|
let head_add_tx2 = write_random_commit(tx2.mut_repo(), &settings);
|
|
|
|
let public_head_add_tx2 = write_random_commit(tx2.mut_repo(), &settings);
|
2021-08-02 04:47:34 +00:00
|
|
|
tx2.mut_repo().add_public_head(&public_head_add_tx2);
|
|
|
|
tx2.commit();
|
|
|
|
|
2022-04-28 05:30:03 +00:00
|
|
|
let repo = repo.reload_at_head(&settings).unwrap();
|
2021-08-02 04:47:34 +00:00
|
|
|
|
|
|
|
let expected_heads = hashset! {
|
|
|
|
head_unchanged.id().clone(),
|
|
|
|
head_add_tx1.id().clone(),
|
|
|
|
head_add_tx2.id().clone(),
|
|
|
|
public_head_unchanged.id().clone(),
|
|
|
|
public_head_remove_tx1.id().clone(),
|
|
|
|
public_head_remove_tx2.id().clone(),
|
|
|
|
public_head_add_tx1.id().clone(),
|
|
|
|
public_head_add_tx2.id().clone(),
|
|
|
|
};
|
|
|
|
assert_eq!(repo.view().heads(), &expected_heads);
|
|
|
|
|
|
|
|
let expected_public_heads = hashset! {
|
|
|
|
public_head_unchanged.id().clone(),
|
|
|
|
public_head_add_tx1.id().clone(),
|
|
|
|
public_head_add_tx2.id().clone(),
|
|
|
|
};
|
|
|
|
assert_eq!(repo.view().public_heads(), &expected_public_heads);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_merge_views_checkout() {
|
|
|
|
// Tests merging of the view's checkout (by performing concurrent operations).
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2021-08-02 04:47:34 +00:00
|
|
|
|
2021-11-26 07:12:00 +00:00
|
|
|
// Workspace 1 gets updated in both transactions.
|
|
|
|
// Workspace 2 gets updated only in tx1.
|
|
|
|
// Workspace 3 gets updated only in tx2.
|
|
|
|
// Workspace 4 gets deleted in tx1 and modified in tx2.
|
|
|
|
// Workspace 5 gets deleted in tx2 and modified in tx1.
|
|
|
|
// Workspace 6 gets added in tx1.
|
|
|
|
// Workspace 7 gets added in tx2.
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut initial_tx = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let commit1 = write_random_commit(initial_tx.mut_repo(), &settings);
|
|
|
|
let commit2 = write_random_commit(initial_tx.mut_repo(), &settings);
|
|
|
|
let commit3 = write_random_commit(initial_tx.mut_repo(), &settings);
|
2021-11-26 07:12:00 +00:00
|
|
|
let ws1_id = WorkspaceId::new("ws1".to_string());
|
|
|
|
let ws2_id = WorkspaceId::new("ws2".to_string());
|
|
|
|
let ws3_id = WorkspaceId::new("ws3".to_string());
|
|
|
|
let ws4_id = WorkspaceId::new("ws4".to_string());
|
|
|
|
let ws5_id = WorkspaceId::new("ws5".to_string());
|
|
|
|
let ws6_id = WorkspaceId::new("ws6".to_string());
|
|
|
|
let ws7_id = WorkspaceId::new("ws7".to_string());
|
|
|
|
initial_tx
|
|
|
|
.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws1_id.clone(), commit1.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
initial_tx
|
|
|
|
.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws2_id.clone(), commit1.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
initial_tx
|
|
|
|
.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws3_id.clone(), commit1.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
initial_tx
|
|
|
|
.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws4_id.clone(), commit1.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
initial_tx
|
|
|
|
.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws5_id.clone(), commit1.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
let repo = initial_tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2021-11-26 07:18:43 +00:00
|
|
|
tx1.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws1_id.clone(), commit2.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
tx1.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws2_id.clone(), commit2.id().clone())
|
|
|
|
.unwrap();
|
2022-09-18 21:46:12 +00:00
|
|
|
tx1.mut_repo().remove_wc_commit(&ws4_id);
|
2021-11-26 07:12:00 +00:00
|
|
|
tx1.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws5_id.clone(), commit2.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
tx1.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws6_id.clone(), commit2.id().clone())
|
|
|
|
.unwrap();
|
2021-08-02 04:47:34 +00:00
|
|
|
tx1.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2021-11-26 07:18:43 +00:00
|
|
|
tx2.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws1_id.clone(), commit3.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
tx2.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws3_id.clone(), commit3.id().clone())
|
|
|
|
.unwrap();
|
2021-11-26 07:12:00 +00:00
|
|
|
tx2.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws4_id.clone(), commit3.id().clone())
|
|
|
|
.unwrap();
|
2022-09-18 21:46:12 +00:00
|
|
|
tx2.mut_repo().remove_wc_commit(&ws5_id);
|
2021-11-26 07:12:00 +00:00
|
|
|
tx2.mut_repo()
|
2022-10-20 23:33:14 +00:00
|
|
|
.set_wc_commit(ws7_id.clone(), commit3.id().clone())
|
|
|
|
.unwrap();
|
2022-02-09 18:40:51 +00:00
|
|
|
// Make sure the end time different, assuming the clock has sub-millisecond
|
|
|
|
// precision.
|
|
|
|
std::thread::sleep(std::time::Duration::from_millis(1));
|
2021-08-02 04:47:34 +00:00
|
|
|
tx2.commit();
|
|
|
|
|
2022-04-28 05:30:03 +00:00
|
|
|
let repo = repo.reload_at_head(&settings).unwrap();
|
2021-08-02 04:47:34 +00:00
|
|
|
|
2023-01-25 16:29:15 +00:00
|
|
|
// We currently arbitrarily pick the first transaction's working-copy commit
|
|
|
|
// (first by transaction end time).
|
2022-09-18 21:46:12 +00:00
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws1_id), Some(commit2.id()));
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws2_id), Some(commit2.id()));
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws3_id), Some(commit3.id()));
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws4_id), None);
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws5_id), None);
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws6_id), Some(commit2.id()));
|
|
|
|
assert_eq!(repo.view().get_wc_commit_id(&ws7_id), Some(commit3.id()));
|
2021-08-02 04:47:34 +00:00
|
|
|
}
|
|
|
|
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
#[test]
|
|
|
|
fn test_merge_views_branches() {
|
|
|
|
// Tests merging of branches (by performing concurrent operations). See
|
|
|
|
// test_refs.rs for tests of merging of individual ref targets.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
let mut_repo = tx.mut_repo();
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_local_tx0 = write_random_commit(mut_repo, &settings);
|
|
|
|
let main_branch_origin_tx0 = write_random_commit(mut_repo, &settings);
|
|
|
|
let main_branch_origin_tx1 = write_random_commit(mut_repo, &settings);
|
|
|
|
let main_branch_alternate_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 14:29:45 +00:00
|
|
|
mut_repo.set_local_branch_target(
|
|
|
|
"main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_local_tx0.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2023-07-11 14:01:54 +00:00
|
|
|
mut_repo.set_remote_branch_target(
|
|
|
|
"main",
|
|
|
|
"origin",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_origin_tx0.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2023-07-11 14:01:54 +00:00
|
|
|
mut_repo.set_remote_branch_target(
|
|
|
|
"main",
|
|
|
|
"alternate",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_alternate_tx0.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2022-12-24 15:38:20 +00:00
|
|
|
let feature_branch_local_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
mut_repo.set_git_ref_target(
|
|
|
|
"feature",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(feature_branch_local_tx0.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_local_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
2023-07-11 14:29:45 +00:00
|
|
|
tx1.mut_repo().set_local_branch_target(
|
|
|
|
"main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_local_tx1.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2023-07-11 14:01:54 +00:00
|
|
|
tx1.mut_repo().set_remote_branch_target(
|
|
|
|
"main",
|
|
|
|
"origin",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_origin_tx1.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2022-12-24 15:38:20 +00:00
|
|
|
let feature_branch_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
2023-07-11 14:29:45 +00:00
|
|
|
tx1.mut_repo().set_local_branch_target(
|
|
|
|
"feature",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(feature_branch_tx1.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
|
|
|
tx1.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_local_tx2 = write_random_commit(tx2.mut_repo(), &settings);
|
2023-07-11 14:29:45 +00:00
|
|
|
tx2.mut_repo().set_local_branch_target(
|
|
|
|
"main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_local_tx2.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
2023-07-11 14:01:54 +00:00
|
|
|
tx2.mut_repo().set_remote_branch_target(
|
|
|
|
"main",
|
|
|
|
"origin",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_origin_tx1.id().clone()),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
|
|
|
tx2.commit();
|
|
|
|
|
2022-04-28 05:30:03 +00:00
|
|
|
let repo = repo.reload_at_head(&settings).unwrap();
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
let expected_main_branch = BranchTarget {
|
2023-07-11 15:22:21 +00:00
|
|
|
local_target: RefTarget::from_legacy_form(
|
|
|
|
[main_branch_local_tx0.id().clone()],
|
|
|
|
[
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
main_branch_local_tx1.id().clone(),
|
|
|
|
main_branch_local_tx2.id().clone(),
|
|
|
|
],
|
2023-07-11 15:22:21 +00:00
|
|
|
),
|
2023-07-15 15:54:50 +00:00
|
|
|
remote_targets: btreemap! {
|
2023-07-12 14:41:38 +00:00
|
|
|
"origin".to_string() => RefTarget::normal(main_branch_origin_tx1.id().clone()),
|
|
|
|
"alternate".to_string() => RefTarget::normal(main_branch_alternate_tx0.id().clone()),
|
2023-07-15 15:54:50 +00:00
|
|
|
},
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
};
|
|
|
|
let expected_feature_branch = BranchTarget {
|
2023-07-11 13:14:59 +00:00
|
|
|
local_target: RefTarget::normal(feature_branch_tx1.id().clone()),
|
2023-07-15 15:54:50 +00:00
|
|
|
remote_targets: btreemap! {},
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
};
|
|
|
|
assert_eq!(
|
|
|
|
repo.view().branches(),
|
|
|
|
&btreemap! {
|
|
|
|
"main".to_string() => expected_main_branch,
|
|
|
|
"feature".to_string() => expected_feature_branch,
|
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_merge_views_tags() {
|
|
|
|
// Tests merging of tags (by performing concurrent operations). See
|
|
|
|
// test_refs.rs for tests of merging of individual ref targets.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
let mut_repo = tx.mut_repo();
|
2022-12-24 15:38:20 +00:00
|
|
|
let v1_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 13:14:59 +00:00
|
|
|
mut_repo.set_tag_target("v1.0", RefTarget::normal(v1_tx0.id().clone()));
|
2022-12-24 15:38:20 +00:00
|
|
|
let v2_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 13:14:59 +00:00
|
|
|
mut_repo.set_tag_target("v2.0", RefTarget::normal(v2_tx0.id().clone()));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let v1_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
tx1.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_tag_target("v1.0", RefTarget::normal(v1_tx1.id().clone()));
|
2022-12-24 15:38:20 +00:00
|
|
|
let v2_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
tx1.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_tag_target("v2.0", RefTarget::normal(v2_tx1.id().clone()));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
tx1.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let v1_tx2 = write_random_commit(tx2.mut_repo(), &settings);
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
tx2.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_tag_target("v1.0", RefTarget::normal(v1_tx2.id().clone()));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
tx2.commit();
|
|
|
|
|
2022-04-28 05:30:03 +00:00
|
|
|
let repo = repo.reload_at_head(&settings).unwrap();
|
2023-07-11 15:22:21 +00:00
|
|
|
let expected_v1 = RefTarget::from_legacy_form(
|
|
|
|
[v1_tx0.id().clone()],
|
|
|
|
[v1_tx1.id().clone(), v1_tx2.id().clone()],
|
|
|
|
);
|
2023-07-11 13:14:59 +00:00
|
|
|
let expected_v2 = RefTarget::normal(v2_tx1.id().clone());
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
assert_eq!(
|
|
|
|
repo.view().tags(),
|
|
|
|
&btreemap! {
|
2023-07-12 14:41:38 +00:00
|
|
|
"v1.0".to_string() => expected_v1,
|
|
|
|
"v2.0".to_string() => expected_v2,
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2021-08-02 04:47:34 +00:00
|
|
|
#[test]
|
|
|
|
fn test_merge_views_git_refs() {
|
|
|
|
// Tests merging of git refs (by performing concurrent operations). See
|
|
|
|
// test_refs.rs for tests of merging of individual ref targets.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-02-05 21:29:55 +00:00
|
|
|
let repo = &test_repo.repo;
|
2021-08-02 04:47:34 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = repo.start_transaction(&settings, "test");
|
2021-08-02 04:47:34 +00:00
|
|
|
let mut_repo = tx.mut_repo();
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
mut_repo.set_git_ref_target(
|
|
|
|
"refs/heads/main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_tx0.id().clone()),
|
2021-08-02 04:47:34 +00:00
|
|
|
);
|
2022-12-24 15:38:20 +00:00
|
|
|
let feature_branch_tx0 = write_random_commit(mut_repo, &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
mut_repo.set_git_ref_target(
|
|
|
|
"refs/heads/feature",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(feature_branch_tx0.id().clone()),
|
2021-08-02 04:47:34 +00:00
|
|
|
);
|
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
tx1.mut_repo().set_git_ref_target(
|
|
|
|
"refs/heads/main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_tx1.id().clone()),
|
2021-08-02 04:47:34 +00:00
|
|
|
);
|
2022-12-24 15:38:20 +00:00
|
|
|
let feature_branch_tx1 = write_random_commit(tx1.mut_repo(), &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
tx1.mut_repo().set_git_ref_target(
|
|
|
|
"refs/heads/feature",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(feature_branch_tx1.id().clone()),
|
2021-08-02 04:47:34 +00:00
|
|
|
);
|
|
|
|
tx1.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let main_branch_tx2 = write_random_commit(tx2.mut_repo(), &settings);
|
2023-07-11 13:42:35 +00:00
|
|
|
tx2.mut_repo().set_git_ref_target(
|
|
|
|
"refs/heads/main",
|
2023-07-11 13:14:59 +00:00
|
|
|
RefTarget::normal(main_branch_tx2.id().clone()),
|
2021-08-02 04:47:34 +00:00
|
|
|
);
|
|
|
|
tx2.commit();
|
|
|
|
|
2022-04-28 05:30:03 +00:00
|
|
|
let repo = repo.reload_at_head(&settings).unwrap();
|
2023-07-11 15:22:21 +00:00
|
|
|
let expected_main_branch = RefTarget::from_legacy_form(
|
|
|
|
[main_branch_tx0.id().clone()],
|
|
|
|
[main_branch_tx1.id().clone(), main_branch_tx2.id().clone()],
|
|
|
|
);
|
2023-07-11 13:14:59 +00:00
|
|
|
let expected_feature_branch = RefTarget::normal(feature_branch_tx1.id().clone());
|
2021-08-02 04:47:34 +00:00
|
|
|
assert_eq!(
|
|
|
|
repo.view().git_refs(),
|
|
|
|
&btreemap! {
|
2023-07-12 14:41:38 +00:00
|
|
|
"refs/heads/main".to_string() => expected_main_branch,
|
|
|
|
"refs/heads/feature".to_string() => expected_feature_branch,
|
2021-08-02 04:47:34 +00:00
|
|
|
}
|
|
|
|
);
|
|
|
|
}
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-12-17 17:34:09 +00:00
|
|
|
#[test]
|
|
|
|
fn test_merge_views_git_heads() {
|
|
|
|
// Tests merging of git heads (by performing concurrent operations). See
|
|
|
|
// test_refs.rs for tests of merging of individual ref targets.
|
|
|
|
let settings = testutils::user_settings();
|
|
|
|
let test_repo = TestRepo::init(false);
|
|
|
|
let repo = &test_repo.repo;
|
|
|
|
|
|
|
|
let mut tx0 = repo.start_transaction(&settings, "test");
|
|
|
|
let tx0_head = write_random_commit(tx0.mut_repo(), &settings);
|
|
|
|
tx0.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_git_head_target(RefTarget::normal(tx0_head.id().clone()));
|
2022-12-17 17:34:09 +00:00
|
|
|
let repo = tx0.commit();
|
|
|
|
|
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
|
|
|
let tx1_head = write_random_commit(tx1.mut_repo(), &settings);
|
|
|
|
tx1.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_git_head_target(RefTarget::normal(tx1_head.id().clone()));
|
2022-12-17 17:34:09 +00:00
|
|
|
|
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
|
|
|
let tx2_head = write_random_commit(tx2.mut_repo(), &settings);
|
|
|
|
tx2.mut_repo()
|
2023-07-11 13:14:59 +00:00
|
|
|
.set_git_head_target(RefTarget::normal(tx2_head.id().clone()));
|
2022-12-17 17:34:09 +00:00
|
|
|
|
2023-07-16 21:26:45 +00:00
|
|
|
let repo = commit_transactions(&settings, vec![tx1, tx2]);
|
2023-07-11 15:22:21 +00:00
|
|
|
let expected_git_head = RefTarget::from_legacy_form(
|
|
|
|
[tx0_head.id().clone()],
|
|
|
|
[tx1_head.id().clone(), tx2_head.id().clone()],
|
|
|
|
);
|
2023-07-12 14:41:38 +00:00
|
|
|
assert_eq!(repo.view().git_head(), &expected_git_head);
|
2022-12-17 17:34:09 +00:00
|
|
|
}
|
|
|
|
|
2022-03-17 03:58:04 +00:00
|
|
|
fn commit_transactions(settings: &UserSettings, txs: Vec<Transaction>) -> Arc<ReadonlyRepo> {
|
|
|
|
let repo_loader = txs[0].base_repo().loader();
|
|
|
|
let mut op_ids = vec![];
|
|
|
|
for tx in txs {
|
|
|
|
op_ids.push(tx.commit().op_id().clone());
|
|
|
|
std::thread::sleep(std::time::Duration::from_millis(1));
|
|
|
|
}
|
2023-01-11 21:12:17 +00:00
|
|
|
let repo = repo_loader.load_at_head(settings).unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
// Test the setup. The assumption here is that the parent order matches the
|
|
|
|
// order in which they were merged (which currently matches the transaction
|
|
|
|
// commit order), so we want to know make sure they appear in a certain
|
|
|
|
// order, so the caller can decide the order by passing them to this
|
|
|
|
// function in a certain order.
|
|
|
|
assert_eq!(*repo.operation().parent_ids(), op_ids);
|
|
|
|
repo
|
|
|
|
}
|
|
|
|
|
2022-03-28 04:12:17 +00:00
|
|
|
#[test]
|
|
|
|
fn test_merge_views_divergent() {
|
|
|
|
// We start with just commit A. Operation 1 rewrites it as A2. Operation 2
|
|
|
|
// rewrites it as A3.
|
|
|
|
let settings = testutils::user_settings();
|
|
|
|
let test_repo = TestRepo::init(false);
|
|
|
|
|
|
|
|
let mut tx = test_repo.repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let commit_a = write_random_commit(tx.mut_repo(), &settings);
|
2022-03-28 04:12:17 +00:00
|
|
|
let repo = tx.commit();
|
|
|
|
|
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-25 20:58:08 +00:00
|
|
|
let commit_a2 = tx1
|
|
|
|
.mut_repo()
|
|
|
|
.rewrite_commit(&settings, &commit_a)
|
2022-12-21 09:13:56 +00:00
|
|
|
.set_description("A2")
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-28 04:12:17 +00:00
|
|
|
tx1.mut_repo().rebase_descendants(&settings).unwrap();
|
|
|
|
|
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-25 20:58:08 +00:00
|
|
|
let commit_a3 = tx2
|
|
|
|
.mut_repo()
|
|
|
|
.rewrite_commit(&settings, &commit_a)
|
2022-12-21 09:13:56 +00:00
|
|
|
.set_description("A3")
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-28 04:12:17 +00:00
|
|
|
tx2.mut_repo().rebase_descendants(&settings).unwrap();
|
|
|
|
|
|
|
|
let repo = commit_transactions(&settings, vec![tx1, tx2]);
|
|
|
|
|
|
|
|
// A2 and A3 should be heads.
|
|
|
|
assert_eq!(
|
|
|
|
*repo.view().heads(),
|
|
|
|
hashset! {commit_a2.id().clone(), commit_a3.id().clone()}
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2022-03-17 03:58:04 +00:00
|
|
|
#[test_case(false ; "rewrite first")]
|
|
|
|
#[test_case(true ; "add child first")]
|
|
|
|
fn test_merge_views_child_on_rewritten(child_first: bool) {
|
|
|
|
// We start with just commit A. Operation 1 adds commit B on top. Operation 2
|
|
|
|
// rewrites A as A2.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = test_repo.repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let commit_a = write_random_commit(tx.mut_repo(), &settings);
|
2022-03-17 03:58:04 +00:00
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-24 17:01:11 +00:00
|
|
|
let commit_b = create_random_commit(tx1.mut_repo(), &settings)
|
2022-03-17 03:58:04 +00:00
|
|
|
.set_parents(vec![commit_a.id().clone()])
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-25 20:58:08 +00:00
|
|
|
let commit_a2 = tx2
|
|
|
|
.mut_repo()
|
|
|
|
.rewrite_commit(&settings, &commit_a)
|
2022-12-21 09:13:56 +00:00
|
|
|
.set_description("A2")
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-04-28 05:30:03 +00:00
|
|
|
tx2.mut_repo().rebase_descendants(&settings).unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
|
|
|
let repo = if child_first {
|
|
|
|
commit_transactions(&settings, vec![tx1, tx2])
|
|
|
|
} else {
|
|
|
|
commit_transactions(&settings, vec![tx2, tx1])
|
|
|
|
};
|
|
|
|
|
|
|
|
// A new B2 commit (B rebased onto A2) should be the only head.
|
|
|
|
let heads = repo.view().heads();
|
|
|
|
assert_eq!(heads.len(), 1);
|
|
|
|
let b2_id = heads.iter().next().unwrap();
|
|
|
|
let commit_b2 = repo.store().get_commit(b2_id).unwrap();
|
|
|
|
assert_eq!(commit_b2.change_id(), commit_b.change_id());
|
|
|
|
assert_eq!(commit_b2.parent_ids(), vec![commit_a2.id().clone()]);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test_case(false, false ; "add child on unchanged, rewrite first")]
|
|
|
|
#[test_case(false, true ; "add child on unchanged, add child first")]
|
|
|
|
#[test_case(true, false ; "add child on rewritten, rewrite first")]
|
|
|
|
#[test_case(true, true ; "add child on rewritten, add child first")]
|
|
|
|
fn test_merge_views_child_on_rewritten_divergent(on_rewritten: bool, child_first: bool) {
|
|
|
|
// We start with divergent commits A2 and A3. Operation 1 adds commit B on top
|
|
|
|
// of A2 or A3. Operation 2 rewrites A2 as A4. The result should be that B
|
|
|
|
// gets rebased onto A4 if it was based on A2 before, but if it was based on
|
|
|
|
// A3, it should remain there.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = test_repo.repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let commit_a2 = write_random_commit(tx.mut_repo(), &settings);
|
2022-12-24 17:01:11 +00:00
|
|
|
let commit_a3 = create_random_commit(tx.mut_repo(), &settings)
|
2022-03-17 03:58:04 +00:00
|
|
|
.set_change_id(commit_a2.change_id().clone())
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-03-17 03:58:04 +00:00
|
|
|
let parent = if on_rewritten { &commit_a2 } else { &commit_a3 };
|
2022-12-24 17:01:11 +00:00
|
|
|
let commit_b = create_random_commit(tx1.mut_repo(), &settings)
|
2022-03-17 03:58:04 +00:00
|
|
|
.set_parents(vec![parent.id().clone()])
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-12-25 20:58:08 +00:00
|
|
|
let commit_a4 = tx2
|
|
|
|
.mut_repo()
|
|
|
|
.rewrite_commit(&settings, &commit_a2)
|
2022-12-21 09:13:56 +00:00
|
|
|
.set_description("A4")
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-04-28 05:30:03 +00:00
|
|
|
tx2.mut_repo().rebase_descendants(&settings).unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
|
|
|
let repo = if child_first {
|
|
|
|
commit_transactions(&settings, vec![tx1, tx2])
|
|
|
|
} else {
|
|
|
|
commit_transactions(&settings, vec![tx2, tx1])
|
|
|
|
};
|
|
|
|
|
|
|
|
if on_rewritten {
|
|
|
|
// A3 should remain as a head. The other head should be B2 (B rebased onto A4).
|
|
|
|
let mut heads = repo.view().heads().clone();
|
|
|
|
assert_eq!(heads.len(), 2);
|
|
|
|
assert!(heads.remove(commit_a3.id()));
|
|
|
|
let b2_id = heads.iter().next().unwrap();
|
|
|
|
let commit_b2 = repo.store().get_commit(b2_id).unwrap();
|
|
|
|
assert_eq!(commit_b2.change_id(), commit_b.change_id());
|
|
|
|
assert_eq!(commit_b2.parent_ids(), vec![commit_a4.id().clone()]);
|
|
|
|
} else {
|
|
|
|
// No rebases should happen, so B and A4 should be the heads.
|
|
|
|
let mut heads = repo.view().heads().clone();
|
|
|
|
assert_eq!(heads.len(), 2);
|
|
|
|
assert!(heads.remove(commit_b.id()));
|
|
|
|
assert!(heads.remove(commit_a4.id()));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test_case(false ; "abandon first")]
|
|
|
|
#[test_case(true ; "add child first")]
|
|
|
|
fn test_merge_views_child_on_abandoned(child_first: bool) {
|
|
|
|
// We start with commit B on top of commit A. Operation 1 adds commit C on top.
|
|
|
|
// Operation 2 abandons B.
|
|
|
|
let settings = testutils::user_settings();
|
2022-05-21 18:20:51 +00:00
|
|
|
let test_repo = TestRepo::init(false);
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx = test_repo.repo.start_transaction(&settings, "test");
|
2022-12-24 15:38:20 +00:00
|
|
|
let commit_a = write_random_commit(tx.mut_repo(), &settings);
|
2022-12-24 17:01:11 +00:00
|
|
|
let commit_b = create_random_commit(tx.mut_repo(), &settings)
|
2022-03-17 03:58:04 +00:00
|
|
|
.set_parents(vec![commit_a.id().clone()])
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
let repo = tx.commit();
|
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx1 = repo.start_transaction(&settings, "test");
|
2022-12-24 17:01:11 +00:00
|
|
|
let commit_c = create_random_commit(tx1.mut_repo(), &settings)
|
2022-03-17 03:58:04 +00:00
|
|
|
.set_parents(vec![commit_b.id().clone()])
|
2022-12-24 05:09:19 +00:00
|
|
|
.write()
|
|
|
|
.unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
2022-11-13 06:29:06 +00:00
|
|
|
let mut tx2 = repo.start_transaction(&settings, "test");
|
2022-03-17 03:58:04 +00:00
|
|
|
tx2.mut_repo()
|
|
|
|
.record_abandoned_commit(commit_b.id().clone());
|
2022-04-28 05:30:03 +00:00
|
|
|
tx2.mut_repo().rebase_descendants(&settings).unwrap();
|
2022-03-17 03:58:04 +00:00
|
|
|
|
|
|
|
let repo = if child_first {
|
|
|
|
commit_transactions(&settings, vec![tx1, tx2])
|
|
|
|
} else {
|
|
|
|
commit_transactions(&settings, vec![tx2, tx1])
|
|
|
|
};
|
|
|
|
|
|
|
|
// A new C2 commit (C rebased onto A) should be the only head.
|
|
|
|
let heads = repo.view().heads();
|
|
|
|
assert_eq!(heads.len(), 1);
|
|
|
|
let id_c2 = heads.iter().next().unwrap();
|
|
|
|
let commit_c2 = repo.store().get_commit(id_c2).unwrap();
|
|
|
|
assert_eq!(commit_c2.change_id(), commit_c.change_id());
|
|
|
|
assert_eq!(commit_c2.parent_ids(), vec![commit_a.id().clone()]);
|
|
|
|
}
|