Re: Git submodule update and the --merge flag when submodule is yet to be checked out

["Spencer E. Olson" <olsonse@umich.edu>]

Yes, this was the intent of this fix last month

On Friday 18 March 2011 15:01, Junio C Hamano wrote:
> Carl Fürstenberg <azatoth@gmail.com> writes:
> > Sorry for re-posting the question but I though I should explain the
> > issue better and to fix the subject line.
> > sub
> > When you are cloning repository containing submodules, and you are
> > using the --merge flag to "git submodule update" the first time, then
> > the submodule instance in question will assume you want to delete all
> > files present in the module.
>
> Is this something we fixed last month?
>
> commit 1b4735d9f3e0b7ea62c7c22f0afcb45e10c46c7e
> Author: Spencer E. Olson <olsonse@umich.edu>
> Date:   Thu Feb 17 09:18:45 2011 -0700
>
>     submodule: no [--merge|--rebase] when newly cloned
>
>     "git submodule update" can be run with either the "--merge" or
> "--rebase" option, or submodule.<name>.update configuration variable can be
> set to "merge" or "rebase, to cause local work to get integrated when
> updating the submodule.
>
>     When a submodule is newly cloned, however, it does not have a check out
>     when a rebase or merge is attempted, leading to a failure.  For newly
>     cloned submodules, simply check out the appropriate revision.  There is
> no local work to integrate with for them.
>
>     Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
>     Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>