Symptom
Check if locally you have a .git/
sub-folder under that folder.
Cause
That would mean the folder (locally) is a nested Git repository, whose tree SHA1 is recorded as a “gitlink” (gray folder with straight white arrow)
What you would then see on GitHub is that gitlink: SHA-1 of the object refers to a commit in another repository, represented by an empty folder name. It is a nested Git repository.
If you see a folder @ xxx
, then it is a submodule entry, meaning your own repository has a .gitmodules
in it, which records, in addition of the gitlink, the actual URL of the remote repository.
It represents the object name of the commit that the super-project expects the nested submodule’s working directory to be at.
In both cases (white arrow with a folder name, or white arrow with folder @ xxx
, folder name and version), it is a Gitlink represented a nested Git repository: a placeholder for another Git repository, hence an empty folder. But in the second case, that empty folder would be referenced/visible in a special .gitmodules
file.
Solution (to remove the white arrow)
In order to restore that folder content:
submodule:
A git clone --recurse-submodules
would restore the content of that submodule in your local repository (as opposed to a nested Git repo, where its URL is not recorded, and the content of the folder would remain empty)
The white arrow would remain on the remote repository, with folder @ version
displaying what SHA1 of the submodule repository is referenced by your project.
Nested Git repository:
Alternatively, you could, if you don’t care about the history of that folder, delete locally its .git
subfolder (assuming it is not a submodule, meaning it is not referenced in a .gitmodules
file in your main repository), add, commit and push.
The white arrow would then disappear, and you would be able to access that folder content on GitHub.