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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 18, 2011, 21:01 UTC
Message-ID: <7vipvgw3c1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTikJo_pjSAmVV3wjWi04io4zWb-_P5p81TYj9tq6@mail.gmail.com>

Carl Fürstenberg <azatoth@gmail.com> writes:

Show 7 quoted lines

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