different git-merge behavior with regard to submodules in 1.6.2.4 vs. 1.6.2.1

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

 



Hello,

I noticed some weirdness lately when trying to merge branches in a
repository containing submodules.  I get the following behavior with git
1.6.2.4:

$ git merge origin/deployed
fatal: cannot read object 83055ffdddde60d41d9811aae77e78be50b329f8
'rubydav': It is a submodule!

Nothing in my history suggests that rubydav was at one point not a
submodule.

I looked at the 1.6.2.4 release notes and noticed the following:

  * "git-merge-recursive" was broken when a submodule entry was involved
in a criss-cross merge situation.

So then I downgraded to the last debian package of git which is 1.6.2.1.
 Now I get a result which is more approachable:

$ git merge origin/deployed
Auto-merging rubydav
CONFLICT (submodule): Merge conflict in rubydav - needs
167a344227c4745031d50a210869e6fb59a5ac03
Auto-merging server
CONFLICT (submodule): Merge conflict in server - needs
82a74ae791c8563ca65f29187d2fe5ebfbc167ea
Automatic merge failed; fix conflicts and then commit the result.

Both merges are from freshly checked out clones.

Is this a bug in 1.6.2.4?  Please let me know what other information I
can provide to help debug the problem.

Thanks,
Tim

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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]