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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 28, 2009, 18:29 UTC
Message-ID: <7v4ow8my1u.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <gt7err$3m4$1@ger.gmane.org>

Tim Olsen <tim@brooklynpenguin.com> writes:

Show 28 quoted lines

> $ 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 for a report.  I think the following commits are involved.

    39d8e27 simplify output of conflicting merge
    0eb6574 update cache for conflicting submodule entries
    f37ae35 add tests for merging with submodules

Clemens, these seem to be yours.  Thoughts?