Re: [PATCH 1/2 (v2)] submodule: no [--merge|--rebase] when newly cloned

Jens Lehmann [off-list ref] writes:

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]

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]