4

I'm working on a git project with several people and we have included an external library as a git submodule. We share a common remote that we regularly push to and pull from.

Since we first added this submodule there were some changes in it, so I did a git submodule update --remote to update it to the newest version. That worked for me and I pushed this to our shared remote. The file at the location of the submodule where the reference to the commit is stored, has changed:

-Subproject commit <old-commit-hash>
+Subproject commit <new-commit-hash>

When my colleagues are pulling changes from our shared remote, they also receive the changed submodule, however this seems to be different from a change in a regular file, since it does not overwrite the old version (what I would expect), but it appears as change when they run git status:

Changes not staged for commit:
    modified:   src/submodule (new commits)

So the file underneath changed (to the new revision that I pushed), but somehow git thinks that the local version of my colleague is newer. However, this is actually the old one, pointing to the previous revision that my colleagues still have.

Now, I like my colleagues, but sometimes they don't really pay attention and all they do is git add . or git commit -a which includes all changes and of course overwrites the changes to the submodule with the reference to the old submodule commit.

Is there a way to enforce this submodule update for all people that pull from this remote? Can this submodule reference file be treated like a normal file that is just updated normally? Or do I have to tell my colleagues to pay more attention and do a git submodule update from time to time?

I hope my question is clear. If not, please ask and I'll try to clarify.

dd23
  • 352
  • 3
  • 10
  • 1
    There are some good tips in the answers to this similar question: http://stackoverflow.com/questions/10443627/force-git-submodule-to-always-stay-current – TruncatedCoDr Jan 18 '16 at 19:15
  • Thanks for the link. I have already looked at that question but wasn't actually able to find a solution for my problem. Please note that I don't want to automatically checkout the submodules HEAD, but instead want to manually push a submodule update to a remote, which others can pull. Do you happen to have a more specific hint for me? – dd23 Jan 18 '16 at 20:20

2 Answers2

2

Or do I have to tell my colleagues to pay more attention and do a git submodule update from time to time?

Ideally this is what they do. If they don't, you could try to add a git-hook which runs a git submodule update after they pulled.

This question may be helpful.

Community
  • 1
  • 1
andreas-hofmann
  • 2,378
  • 11
  • 15
  • Sounds like an interesting approach, but (without having actually tested it) it seems that it suffers form the same problem. According to the [Documentation](http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) git hooks do **not** get copied when a repo is cloned. Therefore, I still have to distribute them manually. This boils down to the same effort as telling everyone to update their submodules. – dd23 Jan 20 '16 at 10:13
  • 1
    True, although I can think of a possible workaround: Include your hooks in a dedicated hooks/-directory in your repo and add a script (something like setup_hooks.sh), which sets up a link in the .git directory to the hooks-directory in the repo. That way the hooks are included in the repo and it's easy to modify them and distribute the changes from then on since they'll get updated with every pull. Of course this would still require every user to run the script once, but I think there's no way around everyone taking at least a *little* step. – andreas-hofmann Jan 21 '16 at 07:50
1

There's not a direct solution to this as after a pull you need to do a submodule update. One thing you can do to combat this issue is you can create and distribute an alias that both pull and does the submodule update for example: 

git config alias.pullAndUpdate '!git pull && git submodule update'

Using this alias will both pull from the remote and update submodules in one command instead of two.

Dom
  • 1,687
  • 6
  • 27
  • 37