David Roundy wrote: [...]
The problem is that the external resolution code assumes that the repository from which you are pulling is itself free from conflicts. In this case you aren't resolving a conflict between your local repository and the remote one, but rather a conflict that's already present in the remote repository. This is a possibility that we don't handle in the external resolve code, since the interface only allows for two versions plus an ancestor being passed to the external handler. It seems natural that one of those versions would be the remove one and one would be the local version.
OK, I think I follow your reasoning - you seem to be saying that in this case the "remote" version is treated as "conflict-free" (i.e. as though a "darcs pull [accept only patch with conflicts]"; "darcs revert" had been done to eliminate any conflict-markers).
In the "cherry-picking" development style darcs allows, this situation seems to have a reasonably high chance of occurring. One possibility as demonstrated here, is that the external merge handler will be lacking information available through the internal merge handling. Do you agree that this is at a minimum undesirable? The potential for loss of information is not described anywhere that I could find in the darcs documentation.
Is it possible to propagate existing conflicts in the remote repository to the external merge command whilst simultaneously dealing with conflicts with the local version?
I'm trying to wrap my head around the issues but not being intimate with darcs is a hindrance. My perspective though is: I can't trust the external merge command to display information as completely as the internal merge functionality, and that makes it much less useful to me, if not dangerous.
-- http://members.dodo.com.au/~netocrat _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
