Force Git submodules to always stay current

Question

I love git submodules. Also, I hate git submodules. What I love about them is how it enables to you to cleanly compartmentalize dependencies etc. I get the point of having them point to a specific commit on a repo, I do. But in my case, I'm building a library that will be used in another project, so I want to keep it in that seperate repo.

However, the annoyance comes when I'm working on a daily basis on this library and I constantly have to switch back to the app using my library to commit the pointer update.

So, is it possible to have a git submodule just always be on the head of the repo it's pointing at while I'm constantly updating and adding to this library?

Answer 1

As I mention in "git submodule tracking latest", you can since git 1.8.2 (March 2013) make a submodule track the HEAD of branch:

git submodule add -b <branch> <repository> [<path>]

A submodule SHA1 is still recorded in the parent repo as a gitlink (special entry in the index)

But a git submodule update --remote will update that entry to the SHA1 matching the HEAD of a branch of the submodule remote repo.

If you have an existing submodule, you can make it follow a branch with:

cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>

cd path/to/your/submodule
git checkout -b branch --track origin/branch
  # if the master branch already exist:
  git branch -u origin/master master

cd /path/to/your/parent/repo
git add path/to/your/submodule
git commit -m "Make submodule tracking a branch"

Answer 2

UPDATE: As of git 1.8.2, there seems to be a solution. Please see VonC's answer down below. The original answer is left here for the users of git < 1.8.2.

---

No, and this is by design. If there were a way to point a submodule to the "current head" of some other repository, then it would be impossible to retrieve a historical version (such as a tagged version) from the main repository. It wouldn't know which version of the submodule to check out.

Having said that, you may be interested in the git subtree script. This offers a different way of working with submodules that may be more compatible with your workflow. I was just reminded of this by the recent post on HN.