Why has GitLab saved one folder of my project as a Subproject commit?

Question

I have started developing a website, saved in my local folders, and I am trying to save it to a GitLab repository. I created a new repository on GitLab and then did the following:

cd existing_folder
git init --initial-branch=main
git remote add origin https://gitlab.com/...
git add .
git commit -m "Initial commit"
git push -u origin main

The project comprises two folders, Server and Client, the Client is a React App. However the Client folder is appearing as a red folder icon that can't be opened:

When I click on the initial commit it says that Client has been added as a Subproject commit:

I don't know what this means, I have built websites with a similar structure before and Gitlab has not done this. I just want the contents of both Client and Server folders to be saved in the repo.

Answer 1

My guess would be that you were doing a git init in the wrong folder. Now your Client folder is maybe a submodule of the actual top git repo.

Check if you have in your Client folder a hidden .git directory

To fix that remove the .git folder in the Client directory. Also check for a file called .gitmodules in the top folder and remove it if it exists.

Answer 2

What you did:

• Created a Git repository holding the client side of the app, and committed stuff to that. This repository resides in client/.git/. It contains files that are presumably named things like main.js and so on (or main.ts and so on, if TypeScript, etc.).

• Created, in .git, a second, over-arching Git repository holding the server side of the app, and committed stuff to that. This repository resides in .git/ and contains files named server/functions.js and so on. Git will be calling this second over-arching repository a superproject. It's just a Git repository though, albeit one with one special property.

Note that as far as Git is concerned, folders don't even exist: files just have names with embedded slashes—always forward slashes, never backslashes—in them. Git will convert these to the folder-and-file arrangements that your OS requires, as needed. This deals with any backslash things that the OS requires as well (e.g., converting names from foo/bar.js to foo\bar.js on Windows). But for the most part this is invisible and we can pretend that we have folders full of files; we're going to work with OS-level files extracted from commits anyway, and those really are files-in-folders. So for the rest of this we'll pretend we do have folders.

Anyway, for good (security) purposes, Git refuses to ever store anything named .git. So all the files in client/.git/* literally cannot be stored: you cannot put the sub-repository in client into the superproject in ., even though ./.git holds server/ and all those files just fine.

Instead, Git will add to the superproject something that Git calls a gitlink. This is an entry that says: After you have cloned and checked out a commit for the superproject, clone another Git repository too. In that new, additional Git repository, I have saved the raw hash ID of the commit you should check out in that sub-project.

This is why you see that instruction:

Subproject commit 327f06...88c

That's the thing that makes this superproject Git repository a superproject: it contains a gitlink named client, and the gitlink itself—which is otherwise just like a file—says 327f06...88c. That 327f06...88c hash ID is the hash ID of a commit in the Git repository that Git should clone and place into a client folder within the superproject.

Now, the trick here is that for Git to run:

git clone <url> client && (cd client && git checkout 327f06...88c)

Git is going to need to know the url to use on this command-line. The gitlink records only the commit hash ID and the path name client. The URL goes into a separate file, as chickahoona mentioned, named .gitmodules.

The thing is, when you ran:

git add .

this will not have created the .gitmodules file for you. To create that file, you must use git submodule add instead of git add. The git submodule add command takes the same kind of argument as git add—the name client in this case—but also takes a URL, which it will add to the .gitmodules file in the form that Git will need to run the git clone command later.

You won't have to run this git clone command on your computer, because you already have a Git repository in client/.git. So the fact that git add . only does half the job doesn't affect your use of this superproject/gitlink pairing. But it means no one else can use your superproject because the cloning directive is missing.

What's not clear is whether you, personally, want to store your server and client in two separate Git repositories like this—one a superproject and one a submodule—or whether you want to store this in, say, three Git repositories:

• one for the server only,
• one for the client only, and
• one to bind them.¹

The last one would be the only superproject in the setup, containing only two gitlinks and a .gitmodules file referring to the two submodules. The server's files would be in a Git repository stored in server/.git and the client's files would be in a Git repository stored in client/.git (as they are now).

Or, perhaps you don't want any submodules at all. In this case, you will need to remove the client/.git folder (or move it elsewhere). This will destroy (or move elsewhere) the entire repository containing the client. You will, however, retain any working tree files from that repository. Now that the inner repository is gone, those working-tree files can be git add-ed to what was the superproject. These files will have named like client/main.js and Git will create a client/ folder and extract them to files named main.js and the like within that client/ folder.

Only you can decide what you want done here. Decide and then proceed: either add the submodule correctly, with git submodule add, or turn the server into a submodule as well and add that, or remove (or move) the client Git repository but not the current version of the client files.

---

¹Three rings for the Elven-kings under the sky,
Seven for the Dwarf Lords in their halls of stone...