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

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

[Carl Fürstenberg]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

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

[-- Attachment #2: submodule_merge_test.sh --]
[-- Type: application/x-sh, Size: 443 bytes --]

[-- Attachment #3: test_output --]
[-- Type: application/octet-stream, Size: 1763 bytes --]

+ mkdir -p test/base test/subproj
+ cd test/subproj
+ git init
Initialized empty Git repository in /home/azatoth/tmp/submerge/test/subproj/.git/
+ echo a
+ git add file
+ git commit -m 'Added file'
[master (root-commit) 9d8576e] Added file
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file
+ cd test/base
+ git init
Initialized empty Git repository in /home/azatoth/tmp/submerge/test/base/.git/
+ git submodule add file:///home/azatoth/tmp/submerge/test/base/../subproj sub
Cloning into sub...
+ git commit -m 'Added subproj'
[master (root-commit) acab4bd] Added subproj
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 sub
+ cd test
+ git clone base cloned
Cloning into cloned...
done.
+ cd cloned
+ git submodule status
-9d8576eda18dd0a2736821d9f60bd34915fdd61c sub
+ git submodule update --init --merge
Submodule 'sub' (file:///home/azatoth/tmp/submerge/test/base/../subproj) registered for path 'sub'
Cloning into sub...
Already up-to-date.
Submodule path 'sub': merged in '9d8576eda18dd0a2736821d9f60bd34915fdd61c'
+ git submodule status
 9d8576eda18dd0a2736821d9f60bd34915fdd61c sub (heads/master)
+ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#	modified:   sub (modified content)
#
no changes added to commit (use "git add" and/or "git commit -a")
+ cd sub
+ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    file
#
+ rm -rf test/base test/subproj test/cloned
+ rmdir test

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

[Junio C Hamano]

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>

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

[Carl Fürstenberg]

2011/3/18 Junio C Hamano <gitster@pobox.com>:
> 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

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

[Spencer E. Olson]

Yes, this was the intent of this fix last month

On Friday 18 March 2011 15:01, Junio C Hamano wrote:
> 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>

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

[Junio C Hamano]

"Spencer E. Olson" <olsonse@umich.edu> writes:

> Yes, this was the intent of this fix last month

Thanks.