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

From: Mikael Magnusson <mikachu@gmail.com>
Date: Apr 30, 2026, 09:10 UTC
Message-ID: <CAHYJk3QZDYv+393ptB9FGuYwSmYKmqw6mWd+fn1bgost-5Ayqg@mail.gmail.com>
In-Reply-To: <CALnO6CBzd0coeyJ9B+EkGWsSNEVTdVLvcVmEraGNxnUm5wXy=g@mail.gmail.com>

On Wed, Apr 29, 2026 at 3:23 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:

Show 34 quoted lines

>
> On Wed, Apr 29, 2026 at 7:27 AM Owen Stephens <owen@owenstephens.co.uk> 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=<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=<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=<depth>
>            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.

One would assume that this 'shallow boundary' on a non-shallow repository would be the *start* of the history, not the current tip, and thus it would be a no-op. Especially if you consider the position of this 'shallow boundary' throughout the process. consider the repo A-B-C-D-E you have a shallow repo with A-B* where * marks the shallow boundary, after another fetch --deepen=2 we get A-B-C-D* and then A-B-C-D-E* you're proposing that it's reasonable that this should instead be *A-B-C-D-E such that another fetch gives us A-B*

> So I'm not sure it should be a no-op.

I think it's pretty obvious that it should be.

> That said, it is possible the behavior changed between 2.53 and 2.54?
> I haven't tried to reproduce or bisect yet.

The mail you're replying to already answers this question.

-- 
Mikael Magnusson