Re: [PATCH 4/5] merge-recursive: handle D/F conflict case more carefully.

From: Junio C Hamano <junkio@cox.net>
Date: Apr 9, 2007, 19:53 UTC
Message-ID: <7vk5wlz5mg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070409185809.GA13212@steel.home>

Alex Riesen <raa.lkml@gmail.com> writes:

Show 7 quoted lines

> Junio C Hamano, Sat, Apr 07, 2007 16:42:55 +0200:
>> +			if (unlink(path)) {
>> +				if (errno == EISDIR) {
>> +					/* something else exists */
>> +					error(msg, path, ": perhaps a D/F conflict?");
>
> isn't this one an F/D conflict?

Yes, as I said in a separate message, the current D/F detector code in merge-recursive does not catch this case in t3030 test and comes to this codepath to write it out:

   From: Junio C Hamano <junkio@cox.net>
   Subject: Re: [PATCH 5/5] t3030: merge-recursive backend test.
   Date: Sat, 07 Apr 2007 22:17:25 -0700
   Message-ID: <7vmz1ja1i2.fsf@assigned-by-dhcp.cox.net>

   > +test_expect_success 'merge-recursive d/f conflict result' '
   > +
   > +	git ls-files -s >actual &&
   > +	(
   > +		echo "100644 $o0 0	A"
   > +		echo "100644 $o0 1	a"
   > +		echo "100644 $o1 2	a"
   > +		echo "100644 $o4 0	a/c"
   > +		echo "100644 $o0 0	b"
   > +		echo "100644 $o1 0	d/e"
   > +	) >expected &&
   > +	git diff -u expected actual
   > +
   > +'

   The expected result of this test is what I find very iffy.  The
   input trees are:

    * Ancestor has a file "a"
    * Our tree has a file "a", which was modified from the
      ancestor's
    * The other tree has a file "a/c"

   merge-recursive.c::git_merge_trees() calls unpack_trees() using
   the threeway_merge function and what it gets back are stage 1
   and 2 entries for "a", and stage 3 entry for "a/c" (you can see
   it by running "git-read-tree -m $c0 $c1 $c4" instead).  But the
   output from merge-recursive has "a/c" resolved down to stage 0.

   The problem is that process_entry() finds that there is only
   stage 3 entry for that path and decides to resolve it.  I think
   it should do the D/F check and leave "a/c" in stage 3.

The part you quoted is merely working this problem around.