Martin Renold <martinxyz@xxxxxx> writes: > test_expect_success "result contains a conflict" "test_cmp expect a1" > > git ls-files --stage > out > cat > expect << EOF > -100644 da056ce14a2241509897fa68bb2b3b6e6194ef9e 1 a1 > +100644 439cc46de773d8a83c77799b7cc9191c128bfcff 1 a1 > 100644 cf84443e49e1b366fac938711ddf4be2d4d1d9e9 2 a1 > 100644 fd7923529855d0b274795ae3349c5e0438333979 3 a1 > EOF I think Nana's patch also had this, but what is this hunk about? IOW, why does stage #1 (common ancestor's version) even change? Is this a virtual ancestor in a criss-cross recursive merge? > @@ -93,8 +93,8 @@ test_expect_success 'refuse to merge binary files' ' > git add binary-file && > git commit -m binary2 && > test_must_fail git merge F > merge.out 2> merge.err && > - grep "Cannot merge binary files: HEAD:binary-file vs. F:binary-file" \ > - merge.err > + grep "Cannot merge binary files: HEAD vs. F" merge.err > + grep "Merge conflict in binary-file" merge.out > ' At the end of the first "grep" && is missing. But more importantly, would this new output format really as informative as you claim, even when the file that cannot be automerged due to its binaryness is not named "binary-file" but simply say "X"? The merge.err output shows that there were some file that failed to merge due to being binary, and merge.out output owuld show that "X" had conflict. Would it be just as easy for the end user to connect these two as it used to be? I for now am assuming no mechanical end user is parsing this output to figure out what to do, but that assumption might even be wrong. -- 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