1

Git 1.8.2 added the possibility to track remote branches with submodule (which is awesome).

# add submodule to track master branch
git submodule add -b master [URL to Git repo];

# update your submodule
# --remote will also fetch and ensure that
# the latest commit from the branch is used
git submodule update --remote

.gitmodules looks like:

[submodule "libraries/shared_libraries"]
    path = libraries/shared_libraries
    url = https://user@bitbucket.org/team/shared_libraries.git
    branch = develop

In our dev shop, all developers use Git >v1.8.2. However, our QA, staging & production servers run either RHEL 6.5 or CentOS, which has 1.7.1 OOTB.

These boxes are typically "pull only", and aren't used to commit code. What should we expect to happen when using "git submodule init/update" from our boxes running 1.7.1? It this a recipe for disaster, or is it a supported use case?

rcourtna
  • 4,589
  • 5
  • 26
  • 27

1 Answers1

1

It this a recipe for disaster, or is it a supported use case?

Supported, in that it would ignore the .gitmodules branch directive.
A git submodule update --init would simply checkout the submodule to its gitlink entry as recorded in the index of the main parent repo.

That gitlink entry would be the SHA1 of the submodule, as last recorded by the parent repo (but a git add + git commit + git push).
As long as both the parent repo has been pushed with that gitlink entry, and the submodule has been pushed with that SHA1 included in its history, both can then be pulled by any client.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So in my example, if my submodule "shared_libraries" advances on the _develop_ branch, to get the latest version with the older git clients, I'd just first have to use a newer git client to `git submodule update --remote`, which would update the gitlink allowing a subsequent `git submodule update` from an older client to get this newer version? Does that sound right? – rcourtna Aug 22 '14 at 19:08
  • @rcourtna yes. As far as the older client is concerned, all its need is a parent repo which references a SHA1 existing in the history of the submodule it will pull. – VonC Aug 22 '14 at 19:18