Alex Riesen <raa.lkml@xxxxxxxxx> writes:
> 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@xxxxxxx>
Subject: Re: [PATCH 5/5] t3030: merge-recursive backend test.
Date: Sat, 07 Apr 2007 22:17:25 -0700
Message-ID: <7vmz1ja1i2.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
> +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.
-
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