8

I tried to find a description for the following gitlab entry in my repo (in files-view):

Screenshot from gitlab

I believe this file was corrupted because I had 'nested' git repos, or better, more than one .git file in the tree (If that makes even sense).

But to be honest, I didn't even know what to google for :P Then I scanned quickly through the reponses here on stackoverflow but I didn't see it either. Can somebody please either tell me where I can find a description of those or tell me what it means? I am not sure if deleting this will cause the rest of the repo to corrupt or some other knock-on effect. GitLab version is 6.2.4.

Thanks in advance,

Michael

Michael3641461
  • 103
  • 1
  • 7

2 Answers2

9

It is a git submodule, and you can type:

git ls-tree HEAD -- ws-dom-full

You will see a gitlink, that is a special entry in the index which records the sha1 of the submodule repo. (Mode 160000)

When you clone the parent repo, that folder is empty.
You need:

git submodule update --init

And you will see the submodule content then.

To remove a submodule (from the index and the disk):

git submodule deinit -- ws-dom-full
git rm -- ws-dom-full
git add -u .
git commit -m "Remove ws-dom-full submodule"
git push
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks VonC. At least I know now what this is. Would I be right in saying that I can then safely 'unlink' that repo with a 'git rm ws-dom-full' command? – Michael3641461 Jun 16 '14 at 11:43
  • @Mic yes, but I would recommend firdt a git submodule deinit yourfolder, then git rm, add, commit, and push. – VonC Jun 16 '14 at 12:09
  • @Michael3641461 I was typing everything from my phone. Now that I am back, I have edited the answer to add links to documentation and to other answers in order to better explain submodules. – VonC Jun 16 '14 at 12:42
2

In my case this turned out to be caused by a colleague that had mistakenly cloned one Git repository within the top level of another (because of the admittedly confusing top level that consisted of only a -redundant- directory with the same name as the repository).

Screenshot from GitLab

The resulting directory layout was like this:

.git
art
  .git
  …
documentatie
  …

For some reason the ‘art’ directory’s contents were never pushed (because of this specific layout?), so after locally cloning the ‘documentatie’ repository, one would end up with an empty ‘art’ sub-directory.

ᴠɪɴᴄᴇɴᴛ
  • 1,613
  • 2
  • 21
  • 28
  • @NieSelam We removed the directory representing a second repository (in this case the `art` directory) and pushed that commit (of the `documentatie` repo in this specific example). – ᴠɪɴᴄᴇɴᴛ Apr 30 '19 at 15:35
  • oh...I don't have access to the directory in my disk. I am supposed to clone it to my machine and start working on it but the src directory does not get cloned. But thanks. – Nie Selam May 01 '19 at 16:16
  • @NieSelam I don’t remember for sure, but I think you won’t be able to remove the sub-project from GitLab. But someone who has already cloned the project could remove it and push. – ᴠɪɴᴄᴇɴᴛ May 08 '19 at 11:19