#147 Regular subdirectory taken as 'Git submodule' where it isn't it, just because there is a .git inside it.

Open
opened 1 month ago by g.cze · 4 comments
g.cze commented 1 month ago

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

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
zPlus commented 1 month ago

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)?

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)?
g.cze commented 1 month ago
Poster

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.

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

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](https://notabug.org/bill-auger/lctv-badges) 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](https://notabug.org/bill-auger/gogs-subrepo-bug/) 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:

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?

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: ``` 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?
Sign in to join this conversation.
No Milestone
No assignee
3 Participants
Loading...
Cancel
Save
There is no content yet.