dedicated is-ancestor / reachability check (like git merge-base --is-ancestor)

[Konstantin Vyatkin (tinovyatkin)]

Summary

There is currently no dedicated API to ask "is commit A an ancestor of commit B", equivalent to git merge-base --is-ancestor.

Current workaround

fn is_descendant_of(
    repo: &gix::Repository,
    ancestor: gix::ObjectId,
    commit: gix::ObjectId,
) -> Result<bool, Error> {
    if ancestor == commit {
        return Ok(true);
    }
    match repo.merge_base(ancestor, commit) {
        Ok(base) => Ok(base.detach() == ancestor),
        Err(gix::repository::merge_base::Error::NotFound { .. }) => Ok(false),
        Err(e) => Err(e.into()),
    }
}

This works, but:

• it computes the full (best) merge base when only a boolean reachability answer is needed — git merge-base --is-ancestor can short-circuit as soon as the candidate ancestor is reached;
• disjoint histories surface as the NotFound error variant, which callers must pattern-match and translate to false, mixing an expected outcome into the error path.

Proposal

Something like Repository::is_ancestor(ancestor, descendant) -> Result<bool, Error> (naming aside), ideally reusing the commit-graph when available like merge_base_with_graph does, and treating disjoint histories as Ok(false).

Context

Needed for a repository-history walker (per-file churn/ownership metrics in mehen) that partitions changes accumulated under a path between a renamed lineage and a newer occupant of the same path by commit ancestry — potentially several reachability queries per rename encountered in the walk, where the merge-base allocation and non-short-circuiting traversal are pure overhead.

[Sebastian Thiel (Byron)]

I recommend using the Repository::merge_base_with_graph()> to make merge-base queries very fast to unblock this and make performance reasonable, albeit not optimal.

It seems two version of the function, is_ancestor[_with_graph](), and a custom implementation based on merge-bases in gix-revision could be sufficient here.

With that said, using tix-traverse::commit::find() one can use the lowest-level primitive to get commit information from a cache if present, and with that one can build own traversals which answer exactly the question one needs, for everything at once. That's typically the best the performance category.

[Konstantin Vyatkin (tinovyatkin)]

Thanks — adopted merge_base_with_graph() with one graph reused across the whole history walk (plus object_cache_size_if_unset for the repeated commit lookups), and it works nicely: a full-history walk with per-rename ancestry partitioning over this repository runs in ~1.5s including tree and blob diffs, so the merge-base overhead is no longer noticeable at our scale.

is_ancestor[_with_graph]() with disjoint histories as Ok(false) would still be a welcome ergonomic addition (the NotFound-as-error pattern-match remains the only wart), but performance-wise we are unblocked. The gix-traverse::commit::find()-based custom traversal is good to know about if a repository ever makes ancestry queries dominant — thanks for the pointer.