0

I am new to git and I am sure this is a pretty simple fix, but here goes..

I have a git repository with two files: client and server.

In my local machine these two files are located in a parent folder, we'll call Parent.

I've been doing my regular git commands off of this Parent folder (add/commit/push) and everything has been going fine until I checked my repo on GitHub and discovered only the server folder was updating. My client folder is completely empty.

If I run git status in the Parent folder I get:

Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   client (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

So, I thought: if I cd into 'client' and do the regular git commands (add/commit/push) this would solve the problem. However, when I check my GitHub repo I see a status change with my commit message next to the client folder, but still no files added. Even if I did solve the problem by doing this, it would be super inconvenient to constantly cd into the client folder to commit client folder changes...

How do I get both folders to update? I want to use my git commands on the Parent folder and have BOTH sub folders update.

Vlad Nitu
  • 147
  • 1
  • 11
sbfergus
  • 1
  • 1
  • 1
    Pay close attention to: `modified: client (new commits)`. See the `(new commits)` part? That means you have a *submodule*. You have not one, but *two* Git repositories. You need to decide whether you want to use submodules in the first place. The remainder of your question cannot be addressed until you understand what submodules are, when to use them, and when not to use them. – torek Aug 23 '22 at 23:09
  • `I have a git repository with two files` _are_ they files ? The git status output indicates it’s a directory. It’d be helpful to add the dir/file structure to the question instead of describing it. – AD7six Aug 24 '22 at 08:11
  • Does this answer your question? [remove git submodule but keep files](https://stackoverflow.com/questions/26752481/remove-git-submodule-but-keep-files) – AD7six Aug 24 '22 at 08:13
  • @torek Can a submodule be created without explicitly telling git to do so? It appears git keeps putting my 'Server' folder inside my 'Client' folder in the git repo on github. But locally I have these folders separated. I've tried just deleting the repo and the local git files and starting again but the same thing happens. – sbfergus Aug 25 '22 at 14:09
  • That depends on what you mean by "explicit": you may not realize that you've done it. If you have nested Git repositories—that is, if you have a top level in `Parent` (i.e., `Parent/.git` exists), and there's *also* a Git repository in `Parent/client`, i.e., `Parent/client/.git` exists, any attempt to `git add client` within `Parent` creates a *gitlink*, which is the primary implementation part of a submodule. Running such a `git add` prints a **very long** hint message to warn you that you've just done this. – torek Aug 25 '22 at 19:52
  • The fundamental problem is that a Git commit *cannot* contain anything named `.../.git/whatever`. This is forbidden internally for security reasons. There was an old bug long ago where you could use `.GIT` instead of `.git` for instance, and Git let you store a repository in a repository, and people used that for all kinds of shenanigans, and ever since that Git is even more careful to make sure that this becomes a submodule instead of a nested repository. – torek Aug 25 '22 at 19:53
  • When you use a submodule, Git adds to its index (and hence to future commits) this "gitlink" thing, which is basically a directive saying "use commit from another Git repository". The gitlink *should* come along with a `.gitmodules` file; the `.gitmodules` file tells the superproject (parent) Git repository where to go to clone the submodule Git repository to put into `path/.git`. The superproject then directs the other Git repository to check out the commit by the stored hash ID. – torek Aug 25 '22 at 19:56
  • This is as close as you can get to a nested Git repository, and Git assumes that if you have nested repositories like this and `git add` the inner one to the outer one, that you must want a submodule (and that you'll manually fix up `.gitmodules` on your own because you know what you are doing). It might be better if `git add` itself refused to do this and required you to run `git submodule add` the first time, but that's not how it was done before, and Git is very big on backwards compatibility even when there are obvious defects with it. – torek Aug 25 '22 at 19:57

0 Answers0