gitbutlerapp/gitbutler · error
Failed to merge bases while cherry picking commit {target}.
Error message
Failed to merge bases while cherry picking commit {target}.
Encountered a conflict while merging the commit's {kind}: {ids}.
Any ids mentioned may be in-memory and inaccessible through the git CLI. What it means
Raised when a cherry pick cannot even establish its merge bases: gix failed to merge the bases (or the 'ontos') needed to transplant the commit. The formatted message lists the commit and the ids involved and notes some ids may exist only in memory, unreachable through the git CLI. This is a hard stop for that pick in the graph rebase.
Source
Thrown at crates/but-rebase/src/graph_rebase/rebase.rs:101
| CherryPickOutcome::Identity(new_id) => {
let mut new_pick = pick.clone();
new_pick.id = new_id;
let new_idx = output_graph.add_node(Step::Pick(new_pick));
graph_mapping.insert(step_idx, new_idx);
if !pick.exclude_from_tracking {
history.update_mapping(pick.id, new_id);
}
new_idx
}
CherryPickOutcome::FailedToMergeBases {
base_merge_failed,
bases,
onto_merge_failed,
ontos,
} => {
// Exit early - the rebase failed because it encountered a commit it couldn't pick
bail!(format_base_merge_error(
pick.id,
base_merge_failed,
bases,
onto_merge_failed,
ontos
));
}
}
}
Step::Reference { refname, mutable } => {
// Immutable references are kept in the graph for traversal
// but never moved, created, or deleted.
if mutable {
let graph_parents = collect_ordered_parents(&self.graph, step_idx);
let first_parent_idx = graph_parents
.first()
.context("References should have at least one parent")?;
let Some(new_idx) = graph_mapping.get(first_parent_idx) else {View on GitHub (pinned to caf1f223d3)
Solutions
- Retry with full history: unshallow/complete partial clones so all base objects exist
- Restructure the edit: rebase onto a different base, or re-merge the affected commits manually
- Capture the ids from the message and inspect those objects via the app (some are in-memory only) to identify the degenerate merge
Defensive patterns
Strategy: fallback
Validate before calling
// Rust: avoid the common cause — ensure history is complete before rebasing
if repo.is_shallow() {
// unshallow or fetch full history first, base merges need all objects
return Err(anyhow::anyhow!("unshallow the repository before this rebase"));
} Try / catch
Catch the bail, extract the commit and base ids from the message for diagnostics, and fall back to manual resolution: re-merge or rebase the affected commits with git, or rebase onto a different base.
Prevention
- Avoid shallow/partial clones for rebase workloads; base merges need every object
- Keep merge-heavy histories on simpler rebase paths, or model them as explicit re-merges
When it happens
Trigger: A Pick step returning `CherryPickOutcome::FailedToMergeBases` — criss-cross or degenerate histories where the recursive merge of base commits itself conflicts, or required base objects are missing (shallow/partial clones).
Common situations: Rebasing across merge-heavy histories, octopus merges, or synthetic in-memory commits created by the editor; corrupted or shallow object databases.
Related errors
- Cherry picks can only be done for single-parent commits. Mer
- Encountered conflict when merging tree {tree_to_merge}{detai
- When using OpenRouter, you must provide a valid API key
- Commit {} was marked as not conflictable, but resulted in a
- merge conflict when computing workspace tree
AI-assisted analysis of gitbutlerapp/gitbutler@caf1f223d3 (2026-08-20).
Data as JSON: /api/errors/3982e7f10bb79075.
Report an issue: GitHub.