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

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

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.

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

Right now there is no easy way to me to check in order to determine whether it was white or black-listed, or even non-specified, if considering this 3rd. possibility makes any sense.

To get this question answered, here is the place where I should look but I'm being unable to do so now.

The chain of happenings that brough the bug at my eyes was that I had a repo already commited, the one of which commit link shared above, and inside which my local copy I moved the root of another repo, then added, commited and pushed (this is exactly the commit link shared above).

Right now there is no easy way to me to check in order to determine whether it was white or black-listed, or even non-specified, if considering this 3rd. possibility makes any sense.
To get this question answered, [here is the place](https://notabug.org/g.cze/practices/src/f934f620eead3758a313426077054143ae596d85) where I should look but I'm being unable to do so now.
The chain of happenings that brough the bug at my eyes was that I had a repo already commited, the one of which commit link shared above, and inside which my local copy I moved the root of another repo, then added, commited and pushed (this is exactly the commit link shared above).

Some checks over the repo's offline copy used when the bug came out reveal that .gitignore didn't exist. So guess is sub repo wasn't neither black nor white-listed.

Aimed at set the issue ahead it follows that the commit pointed to by the above link (ser my previous comment) was checked out (with git checkout variant of the command), and the subfolder containing the .git directory didn't have the regular files it had when originally commited. Guess is that more to browse problems from web interface there is added problem of missing files inside directories with this characteristic.

Some checks over the repo's offline copy used when the bug came out reveal that .gitignore didn't exist. So guess is sub repo wasn't neither black nor white-listed.
Aimed at set the issue ahead it follows that the commit pointed to by the above link (ser my previous comment) was checked out (with git checkout <commit> variant of the command), and the subfolder containing the .git directory didn't have the regular files it had when originally commited. Guess is that more to browse problems from web interface there is added problem of missing files inside directories with this characteristic.

Guess is that more to browse problems from web interface there is added problem of missing files inside directories with this characteristic.

Yes this looks like a simple UI issue, I would be very surprised if any file were missing.

> Guess is that more to browse problems from web interface there is added problem of missing files inside directories with this characteristic.
Yes this looks like a simple UI issue, I would be very surprised if any file were missing.

The first level of problem split/breakdown is between the web application and the git itself.

Not that it means I know which of both sides of the problem would take less effort to go for chaseing after the bug's origin.

If one could have a result that a subdirectory inside a git repo which itself is in comformance to be a standalone repo (not exactly a submodule, say) cannot be recreated on a clean working copy that was previously commited into the repo, and if this result is obtained with a standalone git without the web tier in the middle, then the scope of the problem is narrowed to only git. About the experiment to obtain such a result, there is a nuance on either working just with local operations (commit, clean, checkout) or do it also with some remoting (push, pull) in between. I think, at least to start, without doing the remote part the experiment would be all sufficient.

I believe to remember I possitively knew this problem existed, but it was time ago and I should come with a more recent experiment.

That was just and idea I had in mind and wanted to write here down.

The first level of problem split/breakdown is between the web application and the git itself.
Not that it means I know which of both sides of the problem would take less effort to go for chaseing after the bug's origin.
If one could have a result that a subdirectory inside a git repo which itself is in comformance to be a standalone repo (not exactly a submodule, say) cannot be recreated on a clean working copy that was previously commited into the repo, and if this result is obtained with a standalone git without the web tier in the middle, then the scope of the problem is narrowed to only git. About the experiment to obtain such a result, there is a nuance on either working just with local operations (commit, clean, checkout) or do it also with some remoting (push, pull) in between. I think, at least to start, without doing the remote part the experiment would be all sufficient.
I believe to remember I possitively knew this problem existed, but it was time ago and I should come with a more recent experiment.
That was just and idea I had in mind and wanted to write here down.

im surprised no one mentioned this before - maybe it was seen as obvious - but the fact is that this is not something for notabug to fix - i you want this fixed then it needs to be be reported upstream - they will first want you to verify the bug is present on their demo instance - if they fix the bug then notabug will get the fix on the next upgrade - i left my test-case online - feel free to use that as a demo if you like https://notabug.org/bill-auger/gogs-subrepo-bug/

im surprised no one mentioned this before - maybe it was seen as obvious - but the fact is that this is not something for notabug to fix - i you want this fixed then it needs to be be reported upstream - they will first want you to verify the bug is present on their demo instance - if they fix the bug then notabug will get the fix on the next upgrade - i left my test-case online - feel free to use that as a demo if you like https://notabug.org/bill-auger/gogs-subrepo-bug/