CODEWITHSUNDEEP
gitgit-submodules
Sam
Sam

Reputation: 1105

Git submodules on master

I am new to git submodules, and I notice they always refer to specific commits.

Is there any way for a superproject's submodules to always refer to the head of the master branch, so "git submodule update" or "git pull" in the superproject simply does "git pull" on all submodules.

Thanks.

Upvotes: 9

Views: 2862

Answers (2)

VonC
VonC

Reputation: 1329992

Update 2013, since git 1.8.2, a submodule can follow a branch (and not just reference a fixed commit)

See "git submodule tracking latest".

(Original answer January 2011)

That is one of the differences between git submodules and (for instance) svn:externals.

A submodule is supposed to be a set of files with a different lifecycle, from which you select a specific commit in order to work on your own project (the parent repo).
If that submodule publishes new commit, you shouldn't need to interrupt everything, because suddenly your project don't compile anymore because of the latest evolutions of said submodule.

If, on the other hand, the two set of files are so closely related that modifying anything in one means updating the other, then they should really be part of *one repo.

Upvotes: 11

Cascabel
Cascabel

Reputation: 497752

The short answer is no. The idea is that you know for sure a specific commit of the submodule will work with your project, and you don't want any undefined or unexpected behavior coming in by getting on-the-fly updates. A submodule is directly represented by two things: an entry in .gitmodules, and a gitlink, which is a reference to the SHA1 of the desired commit of the submodule. SHA1, not refname.

What you're asking is really for the superproject to have no idea what's in the submodule. Think about it: different clones of your project could have updated the submodule at different times, and end up with different versions of it there, and then if commits were made in your project, they'd have to record different commits in the submodule. When you merged, you'd have to just ignore what they both say and pull again, probably. The upshot is that your request is avoiding the entire idea of submodules: to know what you have. If you say you're using "master", you'd come back two months from now and have no idea what that meant!

If you want to always get the current master branch, you're better off doing it yourself. Write a script to pull in all the submodules, and run it now and then, committing the updated versions. (Test first, though!) The point here is that with submodules, for every superproject commit, you must know exactly what version of the subproject you're using. It's your choice how often you want to update the version of the submodule; it can be daily if you like.

The alternative would be to add the directory(ies) for the submodule(s) to your gitignore, and write a quick little script to update them (and probably one to clone them too). This would cost you the ability to know what version you had at some point in the past.

Upvotes: 13

Related Questions