Enum jujutsu_lib::evolution::EvolutionRef

pub enum EvolutionRef<'a> {
    Readonly(Arc<ReadonlyEvolution>),
    Mutable(&'a MutableEvolution),
}

Variants

Readonly(Arc<ReadonlyEvolution>)

Mutable(&'a MutableEvolution)

Implementations

impl EvolutionRef<'_>

pub fn successors(&self, commit_id: &CommitId) -> HashSet<CommitId>

pub fn is_obsolete(&self, commit_id: &CommitId) -> bool

pub fn is_orphan(&self, commit_id: &CommitId) -> bool

pub fn is_divergent(&self, change_id: &ChangeId) -> bool

pub fn new_parent(
    &self,
    repo: RepoRef<'_>,
    old_parent_id: &CommitId
) -> HashSet<CommitId>

Given a current parent, finds the new parent candidates. If the current parent is not obsolete, then a singleton set of that commit will be returned.

• If a successor is pruned, its parent(s) will instead be included (or their parents if they are also pruned).

• If the commit has multiple live successors, the tip-most one(s) of them will be chosen.

The second case is more complex than it probably seems. For example, let’s say commit A was split into B, A’, and C (where A’ has the same change id as A). Then C is rebased to somewhere else and becomes C’. We will choose that C’ as effective successor even though it has a different change id and is not a descendant of one that does.