On Wed, Mar 23, 2016 at 1:28 AM, Jared Davison
<jared@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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 is somewhat expected. The depth argument tells Git to cut off the commit
graph such that there is only 1 commit, the rest should not be there.
If you reference a commit in the missing rest, you have an issue as that commit
cannot be found.
As a workaround we try to fetch the missing sha1 if the remote allows it.
(You remote doesn't, so "Direct fetching of that commit failed.")
>
> 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?
The way it currently works, it is always counted from the most recent commit
in the 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.
That sounds interesting. :)
But it may get confusing fast:
* Which reference commit do you mean in the parent? (The topmost commit
I would assume?)
* Up to now the submodule is a self sufficient repository, i.e. it doesn't need
to know about the parent project and could still work great as a standalone
repository. By making depth dependent on the parent project, would there be
a difference in
cd <submodule> && git fetch --depth 12
and
git submodule update --depth 12 <submodule>
?
I thought about adding a new commandline flag instead of overloading depth.
--submodule-enclosure=<n> or such to mean "get all commits the parent is
referencing in its topmost <n> commits".
>
> 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.
Yeah you would rather want a --since=<sha1-or-tag> instead of a --depth
argument I'd assume?
>
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html