gitui-org/gitui · warning · anyhow::Error

Could not select commit. It might not be loaded yet or it…

Error message

Could not select commit. It might not be loaded yet or it might be on a different branch.

What it means

The Revlog component's select_commit() looks the given CommitId up in the list of commits currently materialized in the log view (slabvec of loaded entries). When get_index_of returns None it bails with this message: the id is not in the loaded window - not yet paged in, filtered out by the current branch filter, or reachable only from another branch. It is a soft lookup failure, not repo corruption.

Solutions

Retry after the history has loaded - give the async fetch a beat or trigger fetch_commits(true) first.
Scroll/paginate the log so the target commit is inside the loaded window, or increase the loaded revlog size.
Verify the commit exists and where: git cat-file -t <sha> and git branch --contains <sha>.
Check out the containing branch first, then select the commit.

Example fix

// before
revlog.select_commit(id)?;
// after: tolerate not-yet-loaded ids and retry once after a fetch
if revlog.select_commit(id).is_err() {
    revlog.fetch_commits(true);
    revlog.select_commit(id)?;
}

Defensive patterns

Strategy: retry

Validate before calling

// confirm the id is at least reachable in the repo before driving the UI
let obj = repo.revparse_single(&id.to_string())?;
if !obj.as_commit().is_some_and(|_| true) { /* don't call select_commit at all */ }

Try / catch

match revlog.select_commit(id) {
    Ok(()) => {}
    Err(e) if e.to_string().contains("not be loaded") => {
        wait_for_revlog_load();   // one event-loop tick / input-thread notification
        let _ = revlog.select_commit(id); // best effort second try
    }
    e => e?,
}

Prevention

Give asynchronous history loading a beat before programmatically selecting commits.
Prefer selecting from refs you know are loaded (current branch) before jumping to arbitrary shas.
Treat this bail as 'retry later', not as corruption.

When it happens

Trigger: Calling select_commit right after opening the revlog before the asynchronous history fetch lands; targeting a commit older than the loaded window; the id living on an unmerged branch while the list is filtered to the current one; a stale id after a rebase rewrote history.

Common situations: Deep-linking from file history or blame to an old commit; automation driving gitui's components programmatically; selecting ids taken from another worktree or a reflog.

Related errors

AI-assisted analysis of gitui-org/gitui@2fa693cb6e (2026-08-16). Data as JSON: /api/errors/dc8be060c88ed36a. Report an issue: GitHub.

Appendix: source

Thrown at src/components/commitlist.rs:259

		} else {
			highlighting
		};

		self.select_next_highlight();
		self.set_highlighted_selection_index();
		self.fetch_commits(true);
	}

	///
	pub fn select_commit(&mut self, id: CommitId) -> Result<()> {
		let index = self.commits.get_index_of(&id);

		if let Some(index) = index {
			self.selection = index;
			self.set_highlighted_selection_index();
			Ok(())
		} else {
			anyhow::bail!("Could not select commit. It might not be loaded yet or it might be on a different branch.");
		}
	}

	///
	pub fn highlighted_selection_info(&self) -> (usize, usize) {
		let amount = self
			.highlights
			.as_ref()
			.map(|highlights| highlights.len())
			.unwrap_or_default();
		(self.highlighted_selection.unwrap_or_default(), amount)
	}

	fn set_highlighted_selection_index(&mut self) {
		self.highlighted_selection =
			self.highlights.as_ref().and_then(|highlights| {
				highlights.iter().position(|entry| {
					entry == &self.commits[self.selection]

View on GitHub (pinned to 2fa693cb6e)