Re: [BUG] fatal error during merge

[Alex Riesen <raa.lkml@gmail.com>]

SZEDER Gábor, Thu, Nov 13, 2008 19:09:31 +0100:
> On Thu, Nov 13, 2008 at 06:06:52PM +0100, Anders Melchiorsen wrote:
> > SZEDER Gábor wrote:
> > > It doesn't matter.  The test script errors out at the merge, and not
> > > at the checkout.  Furthermore, it doesn't matter, whether HEAD~,
> > > HEAD~, or HEAD^ is checked out, the results are the same.
> > 
> > Just to be sure, I tried reverting the commit that you bisected -- and my
> > test case still fails.
> 
> Well, oddly enough, your second test case behaves somewhat differently
> than the first one, at least as far as bisect is concerned.  Bisect
> nails down the second test case to 0d5e6c97 (Ignore merged status of
> the file-level merge, 2007-04-26; put Alex on Cc).  Reverting this
> commit on master makes both of your test cases pass.

Well, the case is a bit unfair: all files have the same SHA-1!

Whatever, the code pointed by the commit you bisected does look like a
problem: it does not update the index after refusing to rewrite the
worktree file (because its SHA-1 matches the SHA-1 of the data it
would be rewritten with. So updating the file would be a no-op, just
wasted effort). Instead of reverting the commit, I suggest the
attached patch. It is a long time ago since I looked at the code
(and it is a mess, which I'm feeling a bit ashamed of), so another
lot of reviewing eyeglasses is definitely in order.

From c395f4234ca5492206923e1821a316a777c651cd Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 13 Nov 2008 23:55:04 +0100
Subject: [PATCH] Update index after refusing to rewrite unchanged files

Specifically, which were not changed during recursive merge.
Otherwise the path can stay marked as unresolved in the index,
causing the merge to fail.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>

diff --git a/merge-recursive.c b/merge-recursive.c
index 7472d3e..28f9e12 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -944,14 +944,15 @@ static int process_renames(struct merge_options *o,
 
 				if (mfi.clean &&
 				    sha_eq(mfi.sha, ren1->pair->two->sha1) &&
-				    mfi.mode == ren1->pair->two->mode)
+				    mfi.mode == ren1->pair->two->mode) {
 					/*
 					 * This messaged is part of
 					 * t6022 test. If you change
 					 * it update the test too.
 					 */
 					output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
-				else {
+					add_cacheinfo(mfi.mode, mfi.sha, ren1_dst, 0, 0, ADD_CACHE_OK_TO_ADD);
+				} else {
 					if (mfi.merge || !mfi.clean)
 						output(o, 1, "Renaming %s => %s", ren1_src, ren1_dst);
 					if (mfi.merge)