<div dir="ltr">On Wed, Jul 31, 2013 at 7:50 PM, Vane, Edwin <span dir="ltr"><<a href="mailto:edwin.vane@intel.com" target="_blank">edwin.vane@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
> -----Original Message-----<br>
> From: Manuel Klimek [mailto:<a href="mailto:klimek@google.com">klimek@google.com</a>]<br>
> Sent: Wednesday, July 31, 2013 12:46 PM<br>
> To: Du Toit, Stefanus<br>
> Cc: Vane, Edwin; Daniel Jasper; Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>)<br>
> Subject: Re: [cfe-dev] FW: RFC: YAML as an intermediate format for<br>
> clang::tooling::Replacement data on disk<br>
</div><div class="im">...<br>
> "Merging" is usually merely deduplication, which is not hard. I have the feeling<br>
> that you think there's lots of complexity where it isn't. I'd definitely say that the<br>
> heuristics you propose in order to be able to process headers on their own are<br>
> much higher than the issue of deduplicating edits.<br>
<br>
</div>Is it? Is it not possible for conflicts to occur? If so we must detect these conflicts for the user to sort out. Admittedly, migmerge_git approaches the merge problem from a contextual diff approach but it's the difficulty of detecting conflicts that made that approach so appealing in the first place.<br>
</blockquote><div><br></div><div>Yes, erring out when conflicts occur is good, but I also consider it a rather trivial amount of code.</div><div><br></div></div></div></div>