In an existing bridge, if a git commit is created, in parallel with a
conflicting darcs change, and the darcs change is pushed first, the
bridge will disallow a git push of the patch, as expected.

Pulling the darcs patch into git causes a conflict and resolving the
conflict on the git side creates a commit that merges the remote branch
*into* the local master branch.

When syncing back to darcs, darcs can no longer find it's original
patch, since it has been merged (and is then in a different context). 

A script to demonstrate:

$ darcs init --repo R

$ echo testing > R/a && darcs add --repo R a && darcs rec --repo R -am
'Add a'

$ darcs-fastconvert create-bridge R

# re-enable darcs commands in bridge repo
$ echo 'apply prehook ./_darcs/hooks/pre-apply' >
R_bridge/R/_darcs/prefs/defaults

$ git clone R_bridge/R_git R_git

# Make a Darcs change.
$ echo testing2 >> R/a && darcs rec --repo R -am 'Change a darcs'
$ darcs push --repo R -a R_bridge/R

$ cd R_git
 
# Make a conflicting Git change.
$ echo testing3 >> a && git add a && git commit -am 'Change a git'
# Should fail, since there will be a pulled-in darcs change
$ git push
 
# Should fail, since we will have a confict.
$ git pull
$ echo -e 'testing\ntesting4\ntesting5' > a
$ git add a && git commit -m 'Resolve git conflict'
$ git push
 
$ cd ..
 
# Sync back to Darcs
$ darcs-fastconvert sync R_bridge darcs
 
$ darcs cha --repo R_bridge/R

which will fail with:

> FATAL: Couldn't re-extract previously exported mark from ctx, even
though > we found it previously... for patch: [Change a darcs
> Owen Stephens <darcs@owenstephens.co.uk>**20111122172945
>  Ignore-this: 90aa034f6c804aed0464126c9f936197
> ] 

since "Change a darcs" is now the target of a merge as shown by the
output of changes:

> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge post: 4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   * Resolve git conflict
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge pre-source:
4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <darcs@owenstephens.co.uk>
>   * Change a darcs
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge pre-target:
4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   * Change a git
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <darcs@owenstephens.co.uk>
>   * Add a

What can we do to prevent this? 

Does it matter if we "re-order" the merge when importing into Darcs, so
that the original patches are still available (essentially, make git's
export show "master" as merged into "origin/master", not vice-versa)? 

Does the Git resolution depend on the particular merge ordering? 

Can we just commute out merged-in patches? 

If any darcs repo pulls in the merge, it'll end up with a re-ordered
view of the bridge changes:

$ darcs pull -a --repo R R_bridge/R
$ darcs cha --repo R
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge post: 4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   * Resolve git conflict
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge pre-source:
4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   tagged darcs-fastconvert merge pre-target:
4acfeae1f6208632145618ad1a33e9f4
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <git@owenstephens.co.uk>
>   * Change a git
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <darcs@owenstephens.co.uk>
>   * Change a darcs
> 
> Tue Nov 22 17:29:45 GMT 2011  Owen Stephens <darcs@owenstephens.co.uk>
>   * Add a

The error was caused by another problem, but we still have to decide
what to do with the 'reordering' of the merge caused by importing the
git merge.

So, the remaining questions: 

* Does it matter if we "re-order" the merge when importing into Darcs,
so that the original patches are still available (essentially, make
git's export show "master" as merged into "origin/master", not vice-versa)? 

* Does the Git resolution depend on the particular merge ordering? 

Now the behaviour is as described by the changes following the paragraph
"If any darcs repo pulls in the merge, it'll end up with a re-ordered
view of the bridge changes:" in the previous message.