Re: Git submodule update and the --merge flag when submodule is yet to be checked out
2011/3/18 Junio C Hamano <gitster@pobox.com>:
Show 36 quoted lines
> 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>
> --
> 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
>
Ah, I see, thank you, I was using 1.7.4 and I assume this is for next.
--
Carl Fürstenberg
Carl Fürstenberg <azatoth@gmail.com>