git fetch --unshallow does not work as expected to remove all the limitations imposed by shallow repositories

git fetch --unshallow does not work as expected to remove all the limitations imposed by shallow repositories

[周少坤]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

I just can't figure out the effect of the command `git fetch --unshallow`.

What did you do before the bug happened? (Steps to reproduce your issue)

I downloaded a repo with a shallow clone. Then in my repo's $GIT_DIR,
I get a file named 'shallow' which I found its description in website
'https://git-scm.com/docs/shallow':
> $GIT_DIR/shallow lists commit object names and tells Git to pretend as if they are root commits
> (e.g. "git log" traversal stops after showing them; "git fsck" does not complain saying the commits listed on their "parent" lines do not exist).
When I execute 'git fetch --depth=x' to fetch more history. There is
no doubt that the $GIT_DIR/shallow file exists and lists some commit
objects.
All of the above steps act as expected.
Next, as the doc of 'git fetch --unshallow' described in website
'https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---unshallow':
> If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
> If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
so I execute the command of 'git fetch --unshallow' in my repository
to fetch all commit history.
However, the strange thing is that the shallow file still exists in $GIT_DIR.

What did you expect to happen? (Expected behavior)
As the document says: "If the source repository is complete, convert a
shallow repository to a complete one, removing all the limitations
imposed by shallow repositories."
So, I think the '$GIT_DIR/shallow' file will be deleted after
executing 'git fetch --unshallow' which corresponds to 'removing all
the limitations imposed by shallow repositories.'

What happened instead? (Actual behavior)
And when I execute 'git fetch --unshallow' again, the
'$GIT_DIR/shallow' file is not removed.
What's different between what you expected and what actually happened?
The '$GIT_DIR/shallow' is whether it exists or not after executing
'git fetch --unshallow'.
In my developing application, I use the existence of the
'$GIT_DIR/shallow' file to mark whether a repo's commit history is
completely fetched from a remote source which is really important for
me.
I also tried adding the '--update-shallow' argument which all commands
are 'git fetch --unshallow --update-shallow'. But the
'$GIT_DIR/shallow' file still existed.
But when I try 'git fetch --unshallow --update-shallow' again, the
file will be removed.
So for now, I just execute 'git fetch --unshallow --update-shallow',
and check if '$GIT_DIR/shallow' exists.
If not, the program will return.
If it exists, I execute 'git fetch --unshallow --update-shallow' again
to make sure the  '$GIT_DIR/shallow' file is deleted.

Anything else you want to add:
Maybe it's a bug of 'git fetch'.
If not, I will appreciate it if any guys can give me some ways to
check whether the commit history of one repository which was shallowly
cloned earlier is completely fetched.
Thanks for your reply.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.36.1.windows.1
cpu: x86_64
built from commit: e2ff68a2d1426758c78d023f863bfa1e03cbc768
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19042
compiler info: gnuc: 11.3
libc info: no libc information available
$SHELL (typically, interactive shell):
E:\projects\ugit\ugit\dist\UGit-dev-win32-x64\resources\app\git\usr\bin\bash.exe


[Enabled Hooks]