Git Submodule Problem - Bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

I've encountered strange behavior of git submodule and I cannot think about a way to avoid the problem. I've added a small script that reproduces the problem in the current version of git (1.7.7.3, git-osx-installer).

The problem arises when I pull a commit that switches a submodule with another one and then run git submodule update. Say I have a repo "super" that has one submodule "sub1" in the folder "sub" and a clone "super2". Now I remove the submodule in "super2" and add another one ("sub2") again named "sub", commit this and push it. Now after pulling the commit to "super", I need to run git submodule sync and then git submodule update. 

I expect to end up with the submodule "sub2" in sub. But the log clearly shows that the commits from "sub1" are still there (the master branch belongs to "sub1" while origin/master comes from "sub2").  I get the following output:

> ...
> commit 77d8d11fed3b07e1d4e47b3df9fc44c278694a39
> Author: Manuel Koller <koller@xxxxxxxxxxxxxxxxx>
> Date:   Mon Nov 28 17:46:45 2011 +0100
> 
>     initial commit sub1
> commit 346fe6bd9e7957f10c5e833bb1155153379da41c
> Author: Manuel Koller <koller@xxxxxxxxxxxxxxxxx>
> Date:   Mon Nov 28 17:46:45 2011 +0100
> 
>     initial commit sub2

I think it should be twice the same, and "sub2". I checked also with Charon, on his machine, the two log messages reported are "sub1" which completely baffles me.

Best regards,

Manuel

Attachment: submodule-bug-minimal-example.bash
Description: Binary data


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]