From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 17 Feb 2011 20:25:19 GMT
Subject: Re: [PATCH 1/2 (v2)] submodule: no [--merge|--rebase] when newly cloned
Message-ID: <7vzkpu9zo0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4D5D7A06.6050700@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Am 17.02.2011 17:18, schrieb Spencer E. Olson:
>> Previously, when a new submodule is cloned by running "git submodule update
>> [--merge|--rebase]", the newly cloned submodule does not get checked out and a
>> rebase or merge is incorrectly attempted against an empty working directory.
>> This patch ignores --rebase or --merge for new submodules and instead simply
>> checks out the appropriate revision.
>
> Nice work, thanks!
>
> Just a small thing: This problem also happens when the configuration
> "submodule.<name>.update" is set to either "rebase" or "merge", not only
> when using the command line options. So perhaps you could reword the topic
> to something like "submodule: don't merge or rebase when newly cloned" and
> adjust both commit messages a bit?

I tentatively queued with this rewrite (the patch text is the same as the
one I sent previously).

    From: Spencer E. Olson <olsonse@umich.edu>
    Date: Thu, 17 Feb 2011 09:18:45 -0700
    Subject: [PATCH] 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>