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]
