From: René Scharfe Date: Sat, 02 May 2026 20:26:34 GMT Subject: Re: [Bug] fetch --deepen truncates history in v2.54.0 Message-ID: In-Reply-To: On 5/2/26 11:22 AM, René Scharfe wrote: > On 4/29/26 1:27 PM, Owen Stephens wrote: >>> What did you do before the bug happened? (Steps to reproduce your issue) >> >> Repeatedy called `git fetch --deepen 2` inside a shallow repo that was a >> file:// clone of another repo. Once all commits had been fetched, a subsequent >> `fetch --deepen` appears to "reset" the repo back to being shallow with a depth >> of 2. A reproduction script is included below. This issue appears to have been >> introduced in v2.54.0. >> >>> What did you expect to happen? (Expected behavior) >> >> I expected `git fetch --deepen` in a non-shallow repo with no upstream commits >> to be a no-op. >> >>> What happened instead? (Actual behavior) >> >> `git log` history is truncated to two commits, and repo is considered shallow >> by `git rev-parse --is-shallow-repository`. >> >>> What's different between what you expected and what actually happened? >> >> The previously-present commits in `git log` are missing, and the repo is again >> considered shallow. >> >>> Anything else you want to add: >> >> Commit 3ef68ff seems relevant. > > Indeed, bisect identifies 3ef68ff40e (shallow: handling fetch relative-deepen, > 2026-02-15) and reverting it fixes the issue. Copying its author. Here's a simple fix, but it feels like cheating. A proper one should live in shallow.c, no? diff --git a/builtin/fetch.c b/builtin/fetch.c index a22c319467..310099b96d 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -2664,7 +2664,8 @@ int cmd_fetch(int argc, die(_("negative depth in --deepen is not supported")); if (depth) die(_("options '%s' and '%s' cannot be used together"), "--deepen", "--depth"); - depth = xstrfmt("%d", deepen_relative); + if (is_repository_shallow(the_repository)) + depth = xstrfmt("%d", deepen_relative); } if (unshallow) { if (depth)