For a subdirectory to be a submodule in Git, a .gitmodule will exist in the .git of the root repo directory.
Not just for having a .git, a subdirectory should be interpreted to be a submodule.
The Gogs has a theme style to show submodules differently (eg. with a special icon). It should honor this .gitmodule definition. Currently, it assumes to be a submodule, and show it as this, only based on the subdirectory containing a .git
Thanks @g.cze for reporting. I wonder, is this only a problem with the type of icon displayed by Gogs? Or does it create other problems (eg. you can't open some files)?
Actually, I needed neither the .git placed at subdirectory level nor the submodule feature. So I went quickly removing the unnecesary .git and after a push there was a regular directory showing up in Gogs.
Because I don't use submodule feature beside than casually as per this accident, I can't tell how it's supposed to work.
Just informationally I add, during the short period until the mistaken submodule was fixed back to its directory form, I saw Gogs unability to browse anywhere inside submodules directories.
i just verified this is a legitimate bug
regarding the "ability to browse submodules" - that is a mis-conception of what submodules are - a submodule is NOT part of the repo (only the .gitmodules file is) and so it should not be "browse-able" in the same context - both github and it's copy-cat gogs represent a submodule directory as a hyper-link to the foreign repo - this feature behaves as expected as demonstrated by the 'api' directory here
the actual bug here is that if a subdirectory happens to contain it's own .git/ directory then the HTML text for that subdirectory has the form of a submodule but it is not wrapped in a link and so it is not browse-able as demonstrated here
although such a situation is highly peculiar it is not dis-allowed by git and should be accommodated by gogs
curiously - i was only able to reproduce this when the subdir was white-listed in the outer ./.gitignore - without a .gitignore this bug did not appear and the directory is browse-able except that it's .git directory is not added
git itself could be at least partially to blame for this - during this experiment i noticed several different ways in which git behaved strangely in the presence of such a sub-repo
in the case without a .gitignore, git add --all && git status will show:
git add --all && git status
new file: sub-git-dir/regular-file
in the case with a .gitignore white-list, git add --all && git status will show:
new file: sub-git-dir2
@g.cze - was this your situation? was this directory either blacklisted or white-listed in your .gitignore?