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

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

[Owen Stephens]

> 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.

The following script reproduces the issue in 2.54.0, and does not reproduce the
issue in 2.53.0:

```
mkdir repro.git
cd repro.git

git init

for i in $(seq 1 4); do
  echo "$i" >> file.txt
  git add file.txt
  git commit -m "Change $i"
done

cd ..

git clone --depth 2 "file://$PWD/repro.git" repro_clone.git
cd repro_clone.git

echo "Shallow repo? $(git rev-parse --is-shallow-repository)"
git log --oneline

for i in $(seq 1 3); do
  git fetch --deepen 2
  echo "Shallow repo? $(git rev-parse --is-shallow-repository)"
  git log --oneline
done
```

The key lines in the output are:
```
Shallow repo? true
63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
864e13c (grafted) Change 3
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (6/6), 351 bytes | 175.00 KiB/s, done.

Shallow repo? true
63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
864e13c Change 3
3e05d14 Change 2
1d9fe14 (grafted) Change 1
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)

Shallow repo? false
63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
864e13c Change 3
3e05d14 Change 2
1d9fe14 Change 1
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)

Shallow repo? true
63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
864e13c (grafted) Change 351
```

N.b. that 1d9fe14 was present after the second iteration but missing after the
third, along with `--is-shallow-repository` changing from false back to true.

[System Info]
git version:
git version 2.54.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.7.1
zlib: 1.2.12
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Darwin 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:33:25
PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6041 arm64
compiler info: clang: 21.0.0 (clang-2100.0.123.102)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh

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

[Owen Stephens]

On Wed, Apr 29, 2026 at 12:27 PM Owen Stephens <owen@owenstephens.co.uk> wrote:
> The key lines in the output are:
> ```
> Shallow repo? true
> 63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
> 864e13c (grafted) Change 3
> remote: Enumerating objects: 10, done.
> remote: Counting objects: 100% (10/10), done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 6 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
> Unpacking objects: 100% (6/6), 351 bytes | 175.00 KiB/s, done.
>
> Shallow repo? true
> 63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
> 864e13c Change 3
> 3e05d14 Change 2
> 1d9fe14 (grafted) Change 1
> remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
>
> Shallow repo? false
> 63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
> 864e13c Change 3
> 3e05d14 Change 2
> 1d9fe14 Change 1
> remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
>
> Shallow repo? true
> 63d1ebe (HEAD -> master, origin/master, origin/HEAD) Change 4
> 864e13c (grafted) Change 351
> ```

Apologies, I just noticed that I had inadvertently munged the final
line - it should read "864e13c (grafted) Change 3"

Owen.

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

[D. Ben Knoble]

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.

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

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

[Mikael Magnusson]

On Wed, Apr 29, 2026 at 3:23 PM D. Ben Knoble <ben.knoble@gmail.com> wrote:
>
> 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

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

[René Scharfe]

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.
> The following script reproduces the issue in 2.54.0, and does not reproduce the
> issue in 2.53.0:
> 
> ```
> mkdir repro.git
> cd repro.git
> 
> git init
> 
> for i in $(seq 1 4); do
>   echo "$i" >> file.txt
>   git add file.txt
>   git commit -m "Change $i"
> done
> 
> cd ..
> 
> git clone --depth 2 "file://$PWD/repro.git" repro_clone.git
> cd repro_clone.git
> 
> echo "Shallow repo? $(git rev-parse --is-shallow-repository)"
> git log --oneline
> 
> for i in $(seq 1 3); do
>   git fetch --deepen 2
>   echo "Shallow repo? $(git rev-parse --is-shallow-repository)"
>   git log --oneline
> done
> ```

Nice!  Here's a test for that:


diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index 6588ce6226..fdb1dd9823 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -251,6 +251,16 @@ test_expect_success '.git/shallow is edited by repack' '
 		origin "+refs/heads/*:refs/remotes/origin/*"
 '
 
+test_expect_success 'fetch --deepen does not truncate' '
+	git clone --no-local .git full-clone &&
+	git rev-parse --is-shallow-repository >expect &&
+	git log --oneline >>expect &&
+	git -C full-clone fetch --deepen=1 &&
+	git -C full-clone rev-parse --is-shallow-repository >actual &&
+	git -C full-clone log --oneline >>actual &&
+	test_cmp expect actual
+'
+
 . "$TEST_DIRECTORY"/lib-httpd.sh
 start_httpd
 

 

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

[René Scharfe]

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)

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

[Samo Pogačnik]

[-- Attachment #1: Type: text/plain, Size: 3906 bytes --]

On Sat, 2026-05-02 at 22:26 +0200, René Scharfe wrote:
> 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)
> 

Hi, thanks for pointing out this edge case. Would you care to check the
following change (the provided test is also a bit modified):

diff --git a/shallow.c b/shallow.c
index a156006d88..ec95653132 100644
--- a/shallow.c
+++ b/shallow.c
@@ -245,7 +245,11 @@ struct commit_list *get_shallow_commits(struct object_array
*heads,
                                        int depth, int shallow_flag, int
not_shallow_flag)
 {
        if (shallows && deepen_relative) {
-               depth += get_shallows_depth(heads, shallows);
+               int cur_shallow_depth = get_shallows_depth(heads, shallows);
+               if (cur_shallow_depth)
+                       depth += cur_shallow_depth;
+               else
+                       return NULL;
        }
        return get_shallows_or_depth(heads, NULL, NULL,
                                     depth, shallow_flag, not_shallow_flag);
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index 6588ce6226..9982dd2aa6 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -251,6 +251,16 @@ test_expect_success '.git/shallow is edited by repack' '
                origin "+refs/heads/*:refs/remotes/origin/*"
 '
 
+test_expect_success 'fetch --deepen does not truncate' '
+       git clone --no-local .git full-clone &&
+       git -C full-clone rev-parse --is-shallow-repository >expect &&
+       git -C full-clone log --oneline >>expect &&
+       git -C full-clone fetch --deepen=1 &&
+       git -C full-clone rev-parse --is-shallow-repository >actual &&
+       git -C full-clone log --oneline >>actual &&
+       test_cmp expect actual
+'
+
 . "$TEST_DIRECTORY"/lib-httpd.sh
 start_httpd


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[René Scharfe]

On 5/5/26 9:27 PM, Samo Pogačnik wrote:
> 
> Hi, thanks for pointing out this edge case. Would you care to check the
> following change (the provided test is also a bit modified):

There's spurious wrapping in the patch, but the changes look good to me.

Care to send them with a commit message and sign-off?

René


> diff --git a/shallow.c b/shallow.c
> index a156006d88..ec95653132 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -245,7 +245,11 @@ struct commit_list *get_shallow_commits(struct object_array
> *heads,
>                                         int depth, int shallow_flag, int
> not_shallow_flag)
>  {
>         if (shallows && deepen_relative) {
> -               depth += get_shallows_depth(heads, shallows);
> +               int cur_shallow_depth = get_shallows_depth(heads, shallows);
> +               if (cur_shallow_depth)
> +                       depth += cur_shallow_depth;
> +               else
> +                       return NULL;

Nice.  get_shallows_depth() returns 0 on full clones; translating it to
an empty list of shallow commits makes sense.

>         }
>         return get_shallows_or_depth(heads, NULL, NULL,
>                                      depth, shallow_flag, not_shallow_flag);
> diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
> index 6588ce6226..9982dd2aa6 100755
> --- a/t/t5537-fetch-shallow.sh
> +++ b/t/t5537-fetch-shallow.sh
> @@ -251,6 +251,16 @@ test_expect_success '.git/shallow is edited by repack' '
>                 origin "+refs/heads/*:refs/remotes/origin/*"
>  '
>  
> +test_expect_success 'fetch --deepen does not truncate' '
> +       git clone --no-local .git full-clone &&
> +       git -C full-clone rev-parse --is-shallow-repository >expect &&
> +       git -C full-clone log --oneline >>expect &&
> +       git -C full-clone fetch --deepen=1 &&
> +       git -C full-clone rev-parse --is-shallow-repository >actual &&
> +       git -C full-clone log --oneline >>actual &&

Using the exact same commands to prepare expect and actual creates a
pleasant symmetry.

> +       test_cmp expect actual
> +'
> +
>  . "$TEST_DIRECTORY"/lib-httpd.sh
>  start_httpd
> 

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

[Samo Pogačnik]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Tue, 2026-05-05 at 22:34 +0200, René Scharfe wrote:
> On 5/5/26 9:27 PM, Samo Pogačnik wrote:
> > 
> > Hi, thanks for pointing out this edge case. Would you care to check the
> > following change (the provided test is also a bit modified):
> 
> There's spurious wrapping in the patch, but the changes look good to me.
> 
> Care to send them with a commit message and sign-off?
> 
I will, but it may take a while.

thanks, Samo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 1/1] shallow: fix relative deepen on non-shallow repositories

[Samo Pogačnik]

The previous patch "shallow: handling fetch relative-deepen"
introduced a bug where using --deepen=<n> on a non-shallow
repository incorrectly treated the value as an absolute depth,
resulting in a shallow fetch and truncated history.

This patch prevents any modification when a relative deepen is
requested on a non-shallow repository.

A test is added to ensure that history is not changed when
--deepen is used on a non-shallow repository.

Reported-by: Owen Stephens <owen@owenstephens.co.uk>
Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>
---
 shallow.c                |  6 +++++-
 t/t5537-fetch-shallow.sh | 10 ++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/shallow.c b/shallow.c
index a8ad92e303..610ff3d13b 100644
--- a/shallow.c
+++ b/shallow.c
@@ -245,7 +245,11 @@ struct commit_list *get_shallow_commits(struct object_array *heads,
 					int depth, int shallow_flag, int not_shallow_flag)
 {
 	if (shallows && deepen_relative) {
-		depth += get_shallows_depth(heads, shallows);
+		int cur_shallow_depth = get_shallows_depth(heads, shallows);
+		if (cur_shallow_depth)
+			depth += cur_shallow_depth;
+		else
+			return NULL;
 	}
 	return get_shallows_or_depth(heads, NULL, NULL,
 				     depth, shallow_flag, not_shallow_flag);
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index 6588ce6226..9982dd2aa6 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -251,6 +251,16 @@ test_expect_success '.git/shallow is edited by repack' '
 		origin "+refs/heads/*:refs/remotes/origin/*"
 '
 
+test_expect_success 'fetch --deepen does not truncate' '
+	git clone --no-local .git full-clone &&
+	git -C full-clone rev-parse --is-shallow-repository >expect &&
+	git -C full-clone log --oneline >>expect &&
+	git -C full-clone fetch --deepen=1 &&
+	git -C full-clone rev-parse --is-shallow-repository >actual &&
+	git -C full-clone log --oneline >>actual &&
+	test_cmp expect actual
+'
+
 . "$TEST_DIRECTORY"/lib-httpd.sh
 start_httpd
 
-- 
2.43.0

Re: [PATCH 1/1] shallow: fix relative deepen on non-shallow repositories

[Junio C Hamano]

Samo Pogačnik <samo_pogacnik@t-2.net> writes:

> The previous patch "shallow: handling fetch relative-deepen"

Whose "previous patch" are we talking about in [PATCH 1/1]?

Please refer to the commit with "git show -s --format=reference", if
you are talking about a public commit etched in the history.

> introduced a bug where using --deepen=<n> on a non-shallow
> repository incorrectly treated the value as an absolute depth,
> resulting in a shallow fetch and truncated history.

That's unfortunate.

We obviously should not truncate when asked to "deepen" (i.e., the
user asked to get more history, not reset the number of commits we
have to a specific depth), and making the operation in this
situation a no-op may be a good first step, but should we just do so
silently, instead of giving a warning/diagnosis?

> This patch prevents any modification when a relative deepen is
> requested on a non-shallow repository.
>
> A test is added to ensure that history is not changed when
> --deepen is used on a non-shallow repository.
>
> Reported-by: Owen Stephens <owen@owenstephens.co.uk>
> Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>

Re: [PATCH 1/1] shallow: fix relative deepen on non-shallow repositories

[René Scharfe]

On 5/11/26 2:09 AM, Junio C Hamano wrote:
> 
> We obviously should not truncate when asked to "deepen" (i.e., the
> user asked to get more history, not reset the number of commits we
> have to a specific depth), and making the operation in this
> situation a no-op may be a good first step, but should we just do so
> silently, instead of giving a warning/diagnosis?
Perhaps, but no warning has been given for deepening a non-shallow repo
since the introduction of this option by cccf74e2da (fetch, upload-pack:
--deepen=N extends shallow boundary by N commits, 2016-06-12).

The best place for such a warning would be close to the user, in fetch,
no?  And in its own patch.

René

Re: [PATCH 1/1] shallow: fix relative deepen on non-shallow repositories

[Junio C Hamano]

René Scharfe <l.s.r@web.de> writes:

> Perhaps, but no warning has been given for deepening a non-shallow repo
> since the introduction of this option by cccf74e2da (fetch, upload-pack:
> --deepen=N extends shallow boundary by N commits, 2016-06-12).
>
> The best place for such a warning would be close to the user, in fetch,
> no?  And in its own patch.

Yeah, the lack of warning may or may not be considered a bug, but I
agree that it is totally orthogonal to the problem the patch is
trying to address.

Thanks.

[PATCH v2] shallow: fix relative deepen on non-shallow repositories

[Samo Pogačnik]

The commit "3ef68ff40e (shallow: handling fetch relative-deepen,
2026-02-15)" introduced a bug where using --deepen=<n> on a non-
shallow repository incorrectly treated the value as an absolute
depth, resulting in a shallow fetch and truncated history.

This patch prevents any modification when a relative deepen is
requested on a non-shallow repository.

A test is added to ensure that history is not changed when
--deepen is used on a non-shallow repository.

Reported-by: Owen Stephens <owen@owenstephens.co.uk>
Signed-off-by: Samo Pogačnik <samo_pogacnik@t-2.net>
---
Changes since v1:
- Fixed commit reference in the commit message.

 shallow.c                |  6 +++++-
 t/t5537-fetch-shallow.sh | 10 ++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/shallow.c b/shallow.c
index a8ad92e303..610ff3d13b 100644
--- a/shallow.c
+++ b/shallow.c
@@ -245,7 +245,11 @@ struct commit_list *get_shallow_commits(struct object_array *heads,
 					int depth, int shallow_flag, int not_shallow_flag)
 {
 	if (shallows && deepen_relative) {
-		depth += get_shallows_depth(heads, shallows);
+		int cur_shallow_depth = get_shallows_depth(heads, shallows);
+		if (cur_shallow_depth)
+			depth += cur_shallow_depth;
+		else
+			return NULL;
 	}
 	return get_shallows_or_depth(heads, NULL, NULL,
 				     depth, shallow_flag, not_shallow_flag);
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index 6588ce6226..9982dd2aa6 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -251,6 +251,16 @@ test_expect_success '.git/shallow is edited by repack' '
 		origin "+refs/heads/*:refs/remotes/origin/*"
 '
 
+test_expect_success 'fetch --deepen does not truncate' '
+	git clone --no-local .git full-clone &&
+	git -C full-clone rev-parse --is-shallow-repository >expect &&
+	git -C full-clone log --oneline >>expect &&
+	git -C full-clone fetch --deepen=1 &&
+	git -C full-clone rev-parse --is-shallow-repository >actual &&
+	git -C full-clone log --oneline >>actual &&
+	test_cmp expect actual
+'
+
 . "$TEST_DIRECTORY"/lib-httpd.sh
 start_httpd
 
-- 
2.43.0