Subject: Re: [Bug] fetch --deepen truncates history in v2.54.0

From: René Scharfe <[email-masked]>
Date: Sat, 2 May 2026 22:26:34 +0200

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)