The following dies because the file that is added on both sides does not
exist in the ancestor and the external program (reasonably) complains.
I guess this is something that happens rarely enough for it to be
relatively unimportant, but it may be worth fixing.

---------8<----------------

mkdir un
cd un
darcs init
touch a
darcs add a
darcs record --all --author moi -m "a"
cd ..

mkdir deux 
cd deux 
darcs init
touch a
darcs add a
darcs record --all --author moi -m "a"
cd ..

cd deux
darcs pull ../un --external-merge="opendiff %1 %2 -ancestor %a -merge %o"

"The following dies because the file that is added on both sides does not
exist in the ancestor and the external program (reasonably) complains.
I guess this is something that happens rarely enough for it to be
relatively unimportant, but it may be worth fixing."

Eric, 

What do you think the reasonable fix might look like here? It's not clear to me
offhand what I would expect darcs to do differently here. 

  Mark

On Thu, Jan 31, 2008 at 02:57:39 -0000, Mark Stosberg wrote:
> What do you think the reasonable fix might look like here? It's not clear to me
> offhand what I would expect darcs to do differently here. 

Me neither.  I suppose for this particular case, merge tools might be
happier if an empty version of the file was created in the ancestor.
But how to go about it in a principled fashion is not so clear.

I'm re-framing this as a wishlist item. Since no correct behavior is known, it
seems difficult to think of this as a bug.  I'm also marking at  as "need
example", since it seems like the next step is for someone to go through several
possible conflict cases, and make a proposal about how "external-merge" should
work in each.

Yes, Mark.  That seems like an accurate analysis (and reprioritizing).

I think we can wont-fix this due to darcs-2 semantics accepting duplicate patches.