Jens Lehmann <Jens.Lehmann@xxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxx>
Acked-by: Jens Lehmann <Jens.Lehmann@xxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html