From: D. Ben Knoble Date: Wed, 29 Apr 2026 13:16:00 GMT Subject: Re: [Bug] fetch --deepen truncates history in v2.54.0 Message-ID: In-Reply-To: On Wed, Apr 29, 2026 at 7:27 AM 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. Here's the relevant part of git-fetch(1): --depth= Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a shallow repository created by git clone with --depth= option (see git-clone(1)), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched. --deepen= Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history. I can see how one might read this as implying that when fetching in a non-shallow repository, there's no effect, but I don't think the text explicitly says that. In fact, the first sentence under "--depth" (which is of course relevant for "--deepen") is unconditional. So I'm not sure it should be a no-op. That said, it is possible the behavior changed between 2.53 and 2.54? I haven't tried to reproduce or bisect yet. Best, D. Ben Knoble