---
title: "2026-09-01 Restore mono Git history"
description: "Diagnosed and removed a shallow Git boundary that hid branch history in the shared mono repository."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-09-01 Restore mono Git history

## Work Done

- Diagnosed why `git log` in the `plum-cliff` mono worktree showed only commit `2798c6f3`.
- Confirmed the shared repository was shallow and that `2798c6f3` was listed as a shallow boundary, despite its commit object naming parent `a60f7926`.
- Ran `git fetch --unshallow origin` against the shared mono repository.
- Verified the repository is no longer shallow and that 486 commits are reachable from the branch head.

## Lessons Learned: Pitfalls

- Linked worktrees share the main repository's object database and shallow metadata. A depth-limited fetch performed for one branch can therefore make history appear truncated in another worktree.
- `git show` or ordinary revision traversal can hide a real parent at a shallow boundary. `git cat-file -p HEAD` is useful for confirming the raw parent header.

## Lessons Learned: Improvements

- When `git log` unexpectedly stops at one commit, check `git rev-parse --is-shallow-repository` before investigating force-pushes or orphan branches.
- For linked worktrees, use `git rev-parse --git-common-dir` to find and inspect the shared `shallow` file.

Source: https://docs.virdx.dev/knowledge/inbox/2026-09-01-infrastructure-restore-mono-git-history/index.mdx
