Issue with git submodule update --init --depth=1 submodA

Hello all,

I have encountered a problem with using submodules.

The problem occurs when using

repo-parent$ git submodule update --init --depth=1 submodA

Submodule 'submoduleA' (.../submoduleA.git) registered for path 'submoduleA' Cloning into 'submoduleA'... Fetched in submodule path 'submoduleA', but it did not contain 8a1c22151b510160d7b41a019d7642ab2cd5e085. Direct fetching of that commit failed.

Note the --depth=1 argument.

This all works fine if the head of the submodA master branch is the revision required by the repo-parent as shown in "git submodule list"

However, if submodA's history has progressed by one commit, then --depth=2 is required and this works fine. --depth=1 will no longer work and gives the error as above.

Does depth always have to be counted from the head or most recent commit in the submodule branch?

Could depth be counted from the required commit reference by the parent repo instead of the most recent? If so then --depth=1 could work I think.

The reason I would like to do this is that the history actually contains some fairly large files and I wish to clone only the history for the current version of the files in that most recent commit. This all works great until someone pushes a commit into the submodule. I am using this as part of a continuous integration process which will build branches that reference submodules where the referenced commit may go back a long way back in history.

Trying to determine the correct depth parameter value to use is impossible as with time it will be a growing amount as commits are added to the submodule branch.

Another user found the same issue:  http://stackoverflow.com/a/25875273

I have just compiled the git from "next" branch source, "git version 2.8.0.rc4.233.g1aaf96d" and have confirmed this is still the behaviour.

Thanks for reading my enquiry and for your thoughts on this topic.

Jared