<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 3:52 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I think the main reasons why using a structured format instead of patches here are:</div><div>The upside of "patch" formats doesn't apply here: patches are great if you want them to apply on potentially unknown slightly different revisions. Otherwise I don't see big pros for patches.</div>

<div>On the other hand, patches have a major downside here:</div><div>a) they're too coarse - they're usually line based; refactoring tools often need to handle replacements that fix stuff (non-overlapping) on the same line</div>

<div>b) they're hard to "work with" other than applying them; patch libraries usually just give you that, so if you want to extract the exact ranges on what is changing (for example to do deduplication, or to do other location based calculations) you're re-writing your own patch-parsing code</div>

<div>c) they're much harder to generate from a clang-tool; offset+length+replacement is something you just "have", no need to construct the actual end-result and run algorithms over the strings in the tool</div>

<div><br></div><div>To me patches are basically an optional 3rd level interface here, but we need something more fine grained in a structured format. Using YAML (or JSON) seems an obvious choice for that in the llvm context.</div>
</blockquote></div><br>All of this sounds like a great email to have on an email thread that actually is discussing the design. This is a reply N replies down on a commit with build bot failures mixed in. This needs to be discussed in a better forum.</div>
</div>