Which Git operations break in a shallow clone, and how do you restore the full history?

## Why things break Git's power comes from walking the commit graph. A shallow repository has an artificial edge: the commits named in `.git/shallow` are treated as if they had no parents. Every operation that would walk past that edge is either truncated or fails. ## The specific failures **History reading.** `git log` stops at the boundary. `git blame` attributes every line that was last touched beyond the boundary to the boundary commit, so ownership answers are simply wrong rather than merely incomplete. **Version derivation.** `git describe` looks backwards for the nearest tag. If the tag is older than the boundary, it fails outright. Build systems that stamp a version from `git describe` therefore break in a shallow CI checkout — a very common pipeline bug. **Merge base.** `git merge-base main HEAD` needs a common ancestor. In a shallow, single-branch clone the other branch may not even be present; even when both tips are present at depth 1, their common ancestor is far below the boundary. Consequences ripple outward: `git merge`, `git rebase`, `git cherry-pick` onto a distant base, and `git diff main...HEAD` (which is defined in terms of the merge base) all misbehave. In CI this shows up as "changed files" lists containing the entire repository. **Bisect.** `git bisect` can only pick candidates from the commits you have, so a regression introduced before the boundary is unfindable. ## Restoring history `git fetch --unshallow` asks the remote for everything missing, then deletes the shallow boundary; the repository becomes a normal complete clone. It needs a remote that actually has the full history, and it cannot be combined with `--depth`. `git fetch --deepen=<n>` extends the existing history by `n` further commits without going all the way. `git fetch --depth=<n>` sets an absolute depth measured from the current tips, which can deepen or (rarely) re-shorten. `--shallow-since=<date>` moves the boundary to a date instead of a count. ## The single-branch trap Because `--depth` implies `--single-branch`, an unshallowed repository is still narrow: `remote.origin.fetch` names one branch, so `--unshallow` gives you the full history *of that branch only*. Other branches appear only after you widen the refspec, for example with `git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"` followed by `git fetch`. In CI this catches people out: they unshallow, still cannot find `origin/main`, and conclude the fetch failed. ## The cost calculation Unshallowing downloads exactly the data the shallow clone was avoiding, and it is often *more* expensive than a full clone would have been, because the server cannot reuse a prepared pack as cheaply. If a pipeline consistently ends up unshallowing, the honest answer is to clone deeply in the first place, or to fetch a bounded amount of history up front — for example `--depth 50` when you only need to diff against recent commits, or `--shallow-since` covering the release window. ## Choosing a middle ground Many jobs need only a *little* history. Fetching the base branch at a bounded depth is usually enough for a merge-base diff, and `--shallow-since` is a good fit for "anything in the last month". Where the job truly needs tags or blame, use a full clone or a partial clone rather than shallow, since a partial clone keeps the whole commit graph and only defers file contents.