On Sun, Mar 22, 2009 at 22:55:37 +0200, Dan Pascu wrote: > It seems that this happens if you do not have an external-merge option > defined in ~/.darcs/defaults or you do not specify one on the command > line, but use --mark-conflicts (or don't use any ---xxx-conflicts).
So we can think of --mark-conflicts as being yet another merge tool like one you would supply with external merge (only that it is understands darcs things like replace and move patches, whereas the external merge tool does not) It's funny because your result is: allow-conflicts : leaves a replace patch in unrecord mark-conflicts : nothing new Now with external merge (sans saving)... > $ cat testdata > Given %r/I have a file%r/ do > end > $ darcs whatsnew > replace ./testdata [%r/] / %r/ This isn't surprising because it's just what allow-conflicts does. > 2.2 If I save the merged result from kdiff3, then I get the following > result: > hunk ./testdata 1 > -Given %r/I have a file%r/ do > +Given /I have a file/ do > +end > +Given %r/something else/ do > addfile ./testdata.orig > hunk ./testdata.orig 1 > +Given %r/I have a file%r/ do > +end No surprise there, as far as I can tell. In fact, this is the result we want, right? > 1. Why --allow-conflicts has a reversed replaced applied to working copy? Right. Shouldn't allow-conflicts just nullify both patches? It's almost as if --allow-conflicts and --mark-conflicts have the reverse behaviour > 2. Why both --allow-conflicts and --mark-conflicts have removed the > unrecorded lines. > > With --external-merge defined there are more questions though: > > 1. If external-merge is defined in defaults, --xxx-conflicts are > completely ignored. I believe the external merger should not be used if I > explicitly indicate on the command line --dont-allow-conflicts. I'm not > sure what should happen with --allow-conflicts. That sounds like a bug for which we ought to have a regression test. > 2. Even though there was a replace patch that changed '%r/' to '/', in the > merged result, the lines that were added but not yet recorded in repo2, > still contain %r/. I was under the impression that a replace patch is > useful exactly for these situations as it will combine with the changes > that may have still added the old token on the receiving side and change > those entries to the new token as well. But here we see that the newly > added lines kept the original token and were not affected by the replace > patch. Is this expected behavior, and if so what is the usefulness of a > replace patch if it doesn't do more than a find/replace in the editor > does? At least the documentation explained this expected behavior for the > replace patch and use it a a reason why the replace patch is better than > a find/replace in the editor. Not having had a chance to think too carefully about this, I think this is a consequence of darcs's behaviour of nullifying both sides of the conflict first (and only adding stuff on top of it later in mark-conflicts) -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
