1

The repo is an Android project, and using a submodule called volley. I am trying to add it to git after modifying. I followed this and executed:

git submodule foreach --recursive git add -A .

But the submodule is not added. On the terminal I get this after running the above cmd:

Entering 'app/modules/volley'

But then no new files added. What am I doing wrong here?

phd
  • 82,685
  • 13
  • 120
  • 165
Abrar
  • 6,874
  • 9
  • 28
  • 41

2 Answers2

3

Simply go manually in that submodule, and check its git status: if no files are modified, a git add -A would not add anything.

Or, as said here, the modified content could be a nested repo inside the submodule, which would be ignored.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • How to deal with nested repo? Should I change the remote url? – Abrar Mar 13 '19 at 00:56
  • @Abrar First, do you see inside your submodule a nested re? (a folder with a .git subfolder in it?) – VonC Mar 13 '19 at 05:33
  • Yes, also doing "git remote -v" shows a different origin – Abrar Mar 13 '19 at 05:43
  • @Abrar Do you need that nested repo inside the submodule? (again double-check we are not talking about the submodule itself,but a repo inside the submodule folder, which is itself inside your parent repo) – VonC Mar 13 '19 at 05:45
2

A (modified content) note for a submodule does not distinguish between un-added and added changes to tracked content, which is confusing until you realise why that distinction is irrelevant here.

When you git add a submodule, what you're adding is its current commit id. That is what's supposed to be restored at the submodule path later, in other checkouts in other repos: that commit, the commit with that id. All that gets recorded in your own commit is the id of the submodule commit that should be hunted down and checked out there. If you want.

So git status is telling you you've got some new submodule content that hasn't been committed yet. Git allows you to commit your added aka cached aka indexed aka staged content without regard to any subsequent changes in the worktree, which baffles and even angers people until they hit their stride on what you can do with that, but when you add aka stage aka cache etc a submodule, the added content is just the submodule commit id: there's a necessary little stutter-step in there if you're making new history in that submodule's worktree, you must add and commit your new content so you can stage the submodule's new commit id in the main index.

So whether or not you've git added the new tracked content inside a submodule is immaterial to repos using that submodule, what matters is whether you've committed them, and git status is telling you you have uncommitted changes to tracked content there.

You need to actually cd in to that submodule and (add, but you've already don that, and) commit its new contents. Then you can record the new submodule commit's id (the "I'm sorry, your content is in another castle" line) in the main repo's index before committing that. There's a reason git submodule update --init --recursive isn't the default.

jthill
  • 55,082
  • 5
  • 77
  • 137