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.
|
|
|
|
|
2023-07-10 15:17:00 +00:00
|
|
|
#![allow(missing_docs)]
|
|
|
|
|
2021-11-26 07:12:00 +00:00
|
|
|
use std::collections::{BTreeMap, HashMap, HashSet};
|
2023-07-07 17:45:01 +00:00
|
|
|
use std::fmt;
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2022-05-30 00:18:56 +00:00
|
|
|
use itertools::Itertools;
|
|
|
|
|
2021-09-12 06:52:38 +00:00
|
|
|
use crate::backend::CommitId;
|
2023-02-13 05:57:49 +00:00
|
|
|
use crate::index::Index;
|
2020-12-12 08:00:42 +00:00
|
|
|
use crate::op_store;
|
2023-10-05 15:19:41 +00:00
|
|
|
use crate::op_store::{BranchTarget, RefTarget, RefTargetOptionExt as _, RemoteRef, WorkspaceId};
|
|
|
|
use crate::refs::{iter_named_ref_pairs, merge_ref_targets, TrackingRefPair};
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2023-06-28 10:06:23 +00:00
|
|
|
#[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Hash, Debug)]
|
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
|
|
|
pub enum RefName {
|
|
|
|
LocalBranch(String),
|
|
|
|
RemoteBranch { branch: String, remote: String },
|
|
|
|
Tag(String),
|
|
|
|
GitRef(String),
|
|
|
|
}
|
|
|
|
|
2023-07-07 17:45:01 +00:00
|
|
|
impl fmt::Display for RefName {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
match self {
|
|
|
|
RefName::LocalBranch(name) => write!(f, "{name}"),
|
|
|
|
RefName::RemoteBranch { branch, remote } => write!(f, "{branch}@{remote}"),
|
|
|
|
RefName::Tag(name) => write!(f, "{name}"),
|
|
|
|
RefName::GitRef(name) => write!(f, "{name}"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-05 23:08:13 +00:00
|
|
|
#[derive(PartialEq, Eq, Debug, Clone)]
|
2021-05-31 17:52:30 +00:00
|
|
|
pub struct View {
|
2020-12-12 08:00:42 +00:00
|
|
|
data: op_store::View,
|
|
|
|
}
|
|
|
|
|
2021-05-31 17:52:30 +00:00
|
|
|
impl View {
|
2021-03-14 18:08:31 +00:00
|
|
|
pub fn new(op_store_view: op_store::View) -> Self {
|
2021-05-31 17:52:30 +00:00
|
|
|
View {
|
2021-03-12 05:45:04 +00:00
|
|
|
data: op_store_view,
|
2021-01-04 17:40:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn wc_commit_ids(&self) -> &HashMap<WorkspaceId, CommitId> {
|
|
|
|
&self.data.wc_commit_ids
|
2021-11-26 07:12:00 +00:00
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn get_wc_commit_id(&self, workspace_id: &WorkspaceId) -> Option<&CommitId> {
|
|
|
|
self.data.wc_commit_ids.get(workspace_id)
|
2021-02-01 07:41:59 +00:00
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn workspaces_for_wc_commit_id(&self, commit_id: &CommitId) -> Vec<WorkspaceId> {
|
2022-06-23 08:06:20 +00:00
|
|
|
let mut workspaces_ids = vec![];
|
2022-09-18 21:46:12 +00:00
|
|
|
for (workspace_id, wc_commit_id) in &self.data.wc_commit_ids {
|
|
|
|
if wc_commit_id == commit_id {
|
2022-06-23 08:06:20 +00:00
|
|
|
workspaces_ids.push(workspace_id.clone());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
workspaces_ids
|
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn is_wc_commit_id(&self, commit_id: &CommitId) -> bool {
|
|
|
|
self.data.wc_commit_ids.values().contains(commit_id)
|
2022-05-30 00:18:56 +00:00
|
|
|
}
|
|
|
|
|
2021-02-01 07:41:59 +00:00
|
|
|
pub fn heads(&self) -> &HashSet<CommitId> {
|
|
|
|
&self.data.head_ids
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn public_heads(&self) -> &HashSet<CommitId> {
|
|
|
|
&self.data.public_head_ids
|
|
|
|
}
|
|
|
|
|
2023-10-05 15:19:41 +00:00
|
|
|
/// Iterates pair of local and remote branches by branch name.
|
|
|
|
pub fn branches(&self) -> impl Iterator<Item = (&str, BranchTarget)> {
|
|
|
|
op_store::merge_join_branch_views(&self.data.local_branches, &self.data.remote_views)
|
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-12 22:20:44 +00:00
|
|
|
pub fn tags(&self) -> &BTreeMap<String, RefTarget> {
|
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
|
|
|
&self.data.tags
|
|
|
|
}
|
|
|
|
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn git_refs(&self) -> &BTreeMap<String, RefTarget> {
|
2021-02-01 07:41:59 +00:00
|
|
|
&self.data.git_refs
|
|
|
|
}
|
|
|
|
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn git_head(&self) -> &RefTarget {
|
2023-07-12 14:41:38 +00:00
|
|
|
&self.data.git_head
|
2021-11-28 20:29:04 +00:00
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn set_wc_commit(&mut self, workspace_id: WorkspaceId, commit_id: CommitId) {
|
|
|
|
self.data.wc_commit_ids.insert(workspace_id, commit_id);
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
|
2022-09-18 21:46:12 +00:00
|
|
|
pub fn remove_wc_commit(&mut self, workspace_id: &WorkspaceId) {
|
|
|
|
self.data.wc_commit_ids.remove(workspace_id);
|
2021-11-26 07:12:00 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:29:34 +00:00
|
|
|
pub fn add_head(&mut self, head_id: &CommitId) {
|
|
|
|
self.data.head_ids.insert(head_id.clone());
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:29:34 +00:00
|
|
|
pub fn remove_head(&mut self, head_id: &CommitId) {
|
|
|
|
self.data.head_ids.remove(head_id);
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:29:34 +00:00
|
|
|
pub fn add_public_head(&mut self, head_id: &CommitId) {
|
|
|
|
self.data.public_head_ids.insert(head_id.clone());
|
2021-01-16 18:42:22 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:29:34 +00:00
|
|
|
pub fn remove_public_head(&mut self, head_id: &CommitId) {
|
|
|
|
self.data.public_head_ids.remove(head_id);
|
2021-01-16 18:42:22 +00:00
|
|
|
}
|
|
|
|
|
2023-07-18 10:59:37 +00:00
|
|
|
pub fn get_ref(&self, name: &RefName) -> &RefTarget {
|
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
|
|
|
match &name {
|
|
|
|
RefName::LocalBranch(name) => self.get_local_branch(name),
|
|
|
|
RefName::RemoteBranch { branch, remote } => self.get_remote_branch(branch, remote),
|
|
|
|
RefName::Tag(name) => self.get_tag(name),
|
2023-07-12 15:21:26 +00:00
|
|
|
RefName::GitRef(name) => self.get_git_ref(name),
|
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:44:22 +00:00
|
|
|
/// Sets reference of the specified kind to point to the given target. If
|
|
|
|
/// the target is absent, the reference will be removed.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_ref_target(&mut self, name: &RefName, target: RefTarget) {
|
2023-07-11 14:44:22 +00:00
|
|
|
match name {
|
|
|
|
RefName::LocalBranch(name) => self.set_local_branch_target(name, target),
|
|
|
|
RefName::RemoteBranch { branch, remote } => {
|
|
|
|
self.set_remote_branch_target(branch, remote, target)
|
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:44:22 +00:00
|
|
|
RefName::Tag(name) => self.set_tag_target(name, target),
|
|
|
|
RefName::GitRef(name) => self.set_git_ref_target(name, target),
|
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-10-06 09:33:13 +00:00
|
|
|
/// Returns true if any local or remote branch of the given `name` exists.
|
|
|
|
#[must_use]
|
|
|
|
pub fn has_branch(&self, name: &str) -> bool {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.local_branches.contains_key(name)
|
|
|
|
|| self
|
|
|
|
.data
|
|
|
|
.remote_views
|
|
|
|
.values()
|
|
|
|
.any(|remote_view| remote_view.branches.contains_key(name))
|
2023-10-06 09:33:13 +00:00
|
|
|
}
|
|
|
|
|
2023-10-05 15:19:41 +00:00
|
|
|
// TODO: maybe rename to forget_branch() because this seems unusual operation?
|
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
|
|
|
pub fn remove_branch(&mut self, name: &str) {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.local_branches.remove(name);
|
|
|
|
for remote_view in self.data.remote_views.values_mut() {
|
|
|
|
remote_view.branches.remove(name);
|
|
|
|
}
|
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-09-21 09:49:27 +00:00
|
|
|
/// Iterates local branch `(name, target)`s in lexicographical order.
|
|
|
|
pub fn local_branches(&self) -> impl Iterator<Item = (&str, &RefTarget)> {
|
|
|
|
self.data
|
2023-10-05 15:19:41 +00:00
|
|
|
.local_branches
|
2023-09-21 09:49:27 +00:00
|
|
|
.iter()
|
2023-10-05 15:19:41 +00:00
|
|
|
.map(|(name, target)| (name.as_ref(), target))
|
2023-09-21 09:49:27 +00:00
|
|
|
}
|
|
|
|
|
2023-07-18 10:59:37 +00:00
|
|
|
pub fn get_local_branch(&self, name: &str) -> &RefTarget {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.local_branches.get(name).flatten()
|
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:29:45 +00:00
|
|
|
/// Sets local branch to point to the given target. If the target is absent,
|
|
|
|
/// and if no associated remote branches exist, the branch will be removed.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_local_branch_target(&mut self, name: &str, target: RefTarget) {
|
2023-07-12 14:41:38 +00:00
|
|
|
if target.is_present() {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.local_branches.insert(name.to_owned(), target);
|
2023-07-11 14:29:45 +00:00
|
|
|
} else {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.local_branches.remove(name);
|
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-09-29 04:21:52 +00:00
|
|
|
/// Iterates remote branch `((name, remote_name), target)`s in
|
|
|
|
/// lexicographical order.
|
|
|
|
pub fn remote_branches(&self) -> impl Iterator<Item = ((&str, &str), &RefTarget)> {
|
2023-10-05 15:19:41 +00:00
|
|
|
// TODO: maybe yield RemoteRef instead of RefTarget?
|
|
|
|
op_store::flatten_remote_branches(&self.data.remote_views)
|
2023-09-29 04:21:52 +00:00
|
|
|
}
|
|
|
|
|
2023-07-18 10:59:37 +00:00
|
|
|
pub fn get_remote_branch(&self, name: &str, remote_name: &str) -> &RefTarget {
|
2023-10-05 15:19:41 +00:00
|
|
|
// TODO: maybe return RemoteRef instead of RefTarget?
|
|
|
|
if let Some(remote_view) = self.data.remote_views.get(remote_name) {
|
|
|
|
let maybe_target = remote_view
|
|
|
|
.branches
|
|
|
|
.get(name)
|
|
|
|
.map(|remote_ref| &remote_ref.target);
|
2023-07-18 10:59:37 +00:00
|
|
|
maybe_target.flatten()
|
2023-07-12 22:20:44 +00:00
|
|
|
} else {
|
2023-07-18 10:59:37 +00:00
|
|
|
RefTarget::absent_ref()
|
2023-07-12 22:20:44 +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
|
|
|
}
|
|
|
|
|
2023-07-11 14:01:54 +00:00
|
|
|
/// Sets remote-tracking branch to point to the given target. If the target
|
|
|
|
/// is absent, the branch will be removed.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_remote_branch_target(&mut self, name: &str, remote_name: &str, target: RefTarget) {
|
2023-07-12 14:41:38 +00:00
|
|
|
if target.is_present() {
|
2023-10-05 15:19:41 +00:00
|
|
|
let remote_ref = RemoteRef { target }; // TODO: preserve or reset tracking flag?
|
|
|
|
let remote_view = self
|
|
|
|
.data
|
|
|
|
.remote_views
|
|
|
|
.entry(remote_name.to_owned())
|
|
|
|
.or_default();
|
|
|
|
remote_view.branches.insert(name.to_owned(), remote_ref);
|
|
|
|
} else if let Some(remote_view) = self.data.remote_views.get_mut(remote_name) {
|
|
|
|
remote_view.branches.remove(name);
|
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-10-06 07:17:26 +00:00
|
|
|
/// Iterates local/remote branch `(name, targets)`s of the specified remote
|
|
|
|
/// in lexicographical order.
|
|
|
|
pub fn local_remote_branches<'a>(
|
|
|
|
&'a self,
|
2023-10-05 15:19:41 +00:00
|
|
|
remote_name: &str,
|
2023-10-06 07:17:26 +00:00
|
|
|
) -> impl Iterator<Item = (&'a str, TrackingRefPair<'a>)> + 'a {
|
2023-10-05 15:19:41 +00:00
|
|
|
// TODO: maybe untracked remote target can be translated to absent, and rename
|
2023-10-06 07:17:26 +00:00
|
|
|
// the method accordingly.
|
2023-10-05 15:19:41 +00:00
|
|
|
let maybe_remote_view = self.data.remote_views.get(remote_name);
|
|
|
|
let remote_branches = maybe_remote_view
|
|
|
|
.map(|remote_view| {
|
|
|
|
remote_view
|
|
|
|
.branches
|
|
|
|
.iter()
|
|
|
|
.map(|(name, remote_ref)| (name, &remote_ref.target))
|
2023-10-06 07:17:26 +00:00
|
|
|
})
|
2023-10-05 15:19:41 +00:00
|
|
|
.into_iter()
|
|
|
|
.flatten();
|
|
|
|
iter_named_ref_pairs(&self.data.local_branches, remote_branches).map(
|
|
|
|
|(name, (local_target, remote_target))| {
|
|
|
|
let targets = TrackingRefPair {
|
|
|
|
local_target,
|
|
|
|
remote_target,
|
|
|
|
};
|
|
|
|
(name.as_ref(), targets)
|
|
|
|
},
|
|
|
|
)
|
2023-10-06 07:17:26 +00:00
|
|
|
}
|
|
|
|
|
2023-10-06 17:58:47 +00:00
|
|
|
pub fn remove_remote(&mut self, remote_name: &str) {
|
2023-10-05 15:19:41 +00:00
|
|
|
self.data.remote_views.remove(remote_name);
|
2023-10-06 17:58:47 +00:00
|
|
|
}
|
|
|
|
|
2022-10-19 18:44:39 +00:00
|
|
|
pub fn rename_remote(&mut self, old: &str, new: &str) {
|
2023-10-05 15:19:41 +00:00
|
|
|
if let Some(remote_view) = self.data.remote_views.remove(old) {
|
|
|
|
self.data.remote_views.insert(new.to_owned(), remote_view);
|
2022-10-19 18:44:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-07-18 10:59:37 +00:00
|
|
|
pub fn get_tag(&self, name: &str) -> &RefTarget {
|
|
|
|
self.data.tags.get(name).flatten()
|
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 13:56:33 +00:00
|
|
|
/// Sets tag to point to the given target. If the target is absent, the tag
|
|
|
|
/// will be removed.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_tag_target(&mut self, name: &str, target: RefTarget) {
|
2023-07-12 14:41:38 +00:00
|
|
|
if target.is_present() {
|
2023-07-11 13:56:33 +00:00
|
|
|
self.data.tags.insert(name.to_owned(), target);
|
|
|
|
} else {
|
|
|
|
self.data.tags.remove(name);
|
|
|
|
}
|
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-18 10:59:37 +00:00
|
|
|
pub fn get_git_ref(&self, name: &str) -> &RefTarget {
|
|
|
|
self.data.git_refs.get(name).flatten()
|
2022-11-03 05:30:18 +00:00
|
|
|
}
|
|
|
|
|
2023-07-11 13:42:35 +00:00
|
|
|
/// Sets the last imported Git ref to point to the given target. If the
|
|
|
|
/// target is absent, the reference will be removed.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_git_ref_target(&mut self, name: &str, target: RefTarget) {
|
2023-07-12 14:41:38 +00:00
|
|
|
if target.is_present() {
|
2023-07-11 13:42:35 +00:00
|
|
|
self.data.git_refs.insert(name.to_owned(), target);
|
|
|
|
} else {
|
|
|
|
self.data.git_refs.remove(name);
|
|
|
|
}
|
2021-01-03 08:26:57 +00:00
|
|
|
}
|
|
|
|
|
2023-07-11 13:25:27 +00:00
|
|
|
/// Sets `HEAD@git` to point to the given target. If the target is absent,
|
|
|
|
/// the reference will be cleared.
|
2023-07-12 22:20:44 +00:00
|
|
|
pub fn set_git_head_target(&mut self, target: RefTarget) {
|
2023-07-11 13:25:27 +00:00
|
|
|
self.data.git_head = target;
|
2021-11-28 20:29:04 +00:00
|
|
|
}
|
|
|
|
|
2020-12-12 08:00:42 +00:00
|
|
|
pub fn set_view(&mut self, data: op_store::View) {
|
|
|
|
self.data = data;
|
|
|
|
}
|
|
|
|
|
2021-03-14 05:23:30 +00:00
|
|
|
pub fn store_view(&self) -> &op_store::View {
|
|
|
|
&self.data
|
2021-03-10 22:43:40 +00:00
|
|
|
}
|
2021-03-14 18:08:31 +00:00
|
|
|
|
|
|
|
pub fn store_view_mut(&mut self) -> &mut op_store::View {
|
|
|
|
&mut self.data
|
|
|
|
}
|
2021-06-02 15:47:33 +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
|
|
|
pub fn merge_single_ref(
|
|
|
|
&mut self,
|
2023-02-13 05:57:49 +00:00
|
|
|
index: &dyn Index,
|
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
|
|
|
ref_name: &RefName,
|
2023-07-12 22:20:44 +00:00
|
|
|
base_target: &RefTarget,
|
|
|
|
other_target: &RefTarget,
|
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
|
|
|
) {
|
|
|
|
if base_target != other_target {
|
|
|
|
let self_target = self.get_ref(ref_name);
|
2023-07-18 10:59:37 +00:00
|
|
|
let new_target = merge_ref_targets(index, self_target, base_target, other_target);
|
|
|
|
if new_target != *self_target {
|
2023-07-11 14:44:22 +00:00
|
|
|
self.set_ref_target(ref_name, new_target);
|
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-06-02 15:47:33 +00:00
|
|
|
}
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|