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

[Junio C Hamano <gitster@pobox.com>]

Clemens Buchacher <drizzd@aon.at> writes:

> The fatal error is indeed caused by 0eb6574 (update cache for conflicting
> submodule entries). The problem is also documented by t7405. The test
> exposes a problem even previous to this commit, wherein "git diff" aborts
> with
>
> 	fatal: read error 'sub'
>
> which is why I thought this was broken anyways. Only I see now that I have
> made things worse.

Your "git diff" calls into the combine-diff logic, and it was not updated
when the "gitlink" was added.  With your change you are merely hiding the
issue under the rug.  I've sent a fix as a separate patch.

How about doing this to fix the merge-recursive part?  Looks a lot simpler;
I haven't tested it very much, though.

-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 29 Apr 2009 11:08:18 -0700
Subject: [PATCH] merge-recursive: do not die on a conflicting submodule

We cannot represent the 3-way conflicted state in the work tree
for these entries, but it is normal not to have commit objects
for them in our repository.  Just update the index and the life
will be good.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 merge-recursive.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index d6f0582..a3721ef 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -520,8 +520,12 @@ static void update_file_flags(struct merge_options *o,
 		unsigned long size;
 
 		if (S_ISGITLINK(mode))
-			die("cannot read object %s '%s': It is a submodule!",
-			    sha1_to_hex(sha), path);
+			/*
+			 * We may later decide to recursively descend into
+			 * the submodule directory and update its index
+			 * and/or work tree, but we do not do that now.
+			 */
+			goto update_index;
 
 		buf = read_sha1_file(sha, &type, &size);
 		if (!buf)
-- 
1.6.3.rc3.16.gb37759