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

From: Stefan Beller <sbeller@google.com>
Date: Mar 23, 2016, 17:19 UTC
Message-ID: <CAGZ79kaTACBvBNwAumK035fWG8qooh31JpoooyUmGZEL+4mpOg@mail.gmail.com>
In-Reply-To: <CAECUmHo8Q=N_rTP7NnYaQJ24g9SVrgCmpq1NHVXe1icD6xn7vw@mail.gmail.com>

On Wed, Mar 23, 2016 at 1:28 AM, Jared Davison <jared@medical-objects.com.au> wrote:

Show 15 quoted lines

> 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.")

Show 10 quoted lines

>
> 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".

Show 12 quoted lines

>
> 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?

Show 14 quoted lines

>
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html