Re: [PATCH 1/2 (v2)] submodule: no [--merge|--rebase] when newly cloned
From: Spencer E. Olson <hidden>
Date: 2016-06-15 22:50:35
This looks fine by me. What about the testing patch? It'll be a few hours before I can resubmit with "git submodule status submodule" changed to "git status -s submodule". On Thursday 17 February 2011 13:25, Junio C Hamano wrote:
Jens Lehmann [off-list ref] writes:quoted
Am 17.02.2011 17:18, schrieb Spencer E. Olson:quoted
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 [off-list ref] 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 [off-list ref] Acked-by: Jens Lehmann [off-list ref] Signed-off-by: Junio C Hamano [off-list ref]