threads / discuss / 26777

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

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

## tl;dr

5 messages between Mar 18, 2011 and Mar 18, 2011.

replies: 4people: 3as markdown or json

Carl Fürstenberg· Mar 18, 2011, 18:25 UTC · lore

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.

Please look at attachment for a testcase and how the result might look like. Unless this is not the intended behavior, then I would suggest changing --merge (and possible --rebase) to not assume a non-existent repository to be a empty one.

The man pages says "Merge the commit recorded in the superproject into the current branch of the submodule", but we have no current branch of the submodule.

I would be happy for any reply, and sorry again for the repost.
/Carl Fürstenberg
Junio C Hamano· Mar 18, 2011, 21:01 UTC · re: Carl Fürstenberg · lore

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

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>
Carl Fürstenberg· Mar 18, 2011, 21:06 UTC · re: Junio C Hamano · lore

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

2011/3/18 Junio C Hamano <gitster@pobox.com>:
Show 36 quoted lines
> Carl Fürstenberg <azatoth@gmail.com> writes:
>
>> 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>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Ah, I see, thank you, I was using 1.7.4 and I assume this is for next.
-- 
Carl Fürstenberg
Spencer E. Olson· Mar 18, 2011, 21:24 UTC · re: Junio C Hamano · lore

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

Yes, this was the intent of this fix last month
On Friday 18 March 2011 15:01, Junio C Hamano wrote:
Show 30 quoted lines
> Carl Fürstenberg <azatoth@gmail.com> writes:
> > 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>

← back to recent threads