CODEWITHSUNDEEP
git
Granger Obliviate
Granger Obliviate

Reputation: 151

git add does not stage changes to commit

So I'm having this:

Changes not staged for commit:

modified: submodules/TIMER (modified content)

When I try to do "git add ." nothing happens. How do I set this change to push to my git repository?

Upvotes: 0

Views: 716

Answers (2)

torek
torek

Reputation: 490098

You don't, because that's not a file.

More specifically, if you see (modified content)—and you do—you have a submodule. A submodule is a separate Git repository. We take one of these two Git repositories, which we call a superproject, and place it in control over another otherwise-independent Git repository, which we call a submodule.

When you work in the superproject—which is what you are doing now—the superproject commit says only one thing about the submodule: that the submodule, in this case, submodules/TIMER, should have commit ______ checked out. This blank gets filled in when you run git add:

git add submodules/TIMER

tells your superproject Git to run:

(cd submodules/TIMER; git rev-parse HEAD)

to get the raw hash ID of the commit that is checked out in the submodule (usually as a "detached HEAD"). That hash ID, whatever it is, fills in the blank.

So what is there to do about this?

What's going on here is that in the other Git repository—the submodule—there are some modified files that have not been put into any commit. This cannot be handled or fixed in the superproject. It must be handled in the submodule.

Therefore, you need to:

cd submodules/TIMER

(perhaps in another window so that you don't disturb your work in the superproject; or, if you like, just cd back to the superproject once you're done). You can now work in the submodule as a normal everyday Git repository—except for one problem, that is: the superproject Git forced your submodule Git to go into "detached HEAD" mode. This is not a normal mode in which you should do any work.

Unfortunately, someone or something has already done some work, producing this "modified content" as viewed from above (from the superproject). But at least, if you run git status now, in the submodule Git repository, you can see what is modified and figure out what to do. I cannot tell you what to do because I do not have this information.

In any case, once you figure out what to do, you can then:

  • make a new commit, if that's appropriate;
  • erase the changes here (e.g., git reset --hard), if that's appropriate; and/or
  • do whatever it is that's appropriate.

Let's assume for now that making a new commit is appropriate, and you figured out which branch to use or made a new branch or whatever it was that was appropriate, and did actually make the new commit. So, having made a new commit, you can now push or pull-request the new commit. Once the new commit is available to everyone, it's now safe to return to working in the superproject.

You can return to working in the superproject earlier, but note that once you make a new commit in the superproject that refers to your new submodule commit, if no one else can get that submodule commit, no one else can use the new superproject commit either. So it's often advisable to wait until any new submodule commit is actually available to everyone.

So, now you return to the superproject. The submodule is on the new correct commit hash, so now you just run:

git add submodules/TIMER

and now you can git commit as usual (see also Alyson Maia's answer).

Upvotes: 2

Alyson Maia
Alyson Maia

Reputation: 810

By the name of the folder I'll suppose it's a Git Submodule. So it is a different repository from the source and you need to commit and push the changes inside first, then push the outside project to update the submodule reference.

Changes inside submodule

$ cd submodules/TIMER
$ git add .
$ git commit -m "my submodule changes..."
$ git push

Update submodule on parent repo

$ cd ../..
$ git add submodules/TIMER
$ git commit -m "updating submodule reference..."
$ git push

Upvotes: 0

Related Questions