<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 11:30 AM, Markus Seeber <span dir="ltr"><<a href="mailto:markus.seeber@spectralbird.de" target="_blank">markus.seeber@spectralbird.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/31/2016 09:34 AM, Filipe Coelho wrote:<br>
> In my opinion we should get back to the original jack1 code before<br>
> uncrustify messed up things.<br>
> And then try to generate a clean patch. I'm willing to do the clean<br>
> patch if Paul reverts uncrustify changes.<br>
> @Paul: is that ok?<br>
<br>
</span>After having a look at the patch myself and the commit history, this<br>
seems to be a reasonable approach but there is still the problem, that<br>
commits after the uncrustify step may depend on that one and might need<br>
to be rebased?<br>
<br>
@Paul Have the uncrustify changes from<br>
c758cdf4f6e959b92683f2dba6ce8617ac4f0a83 been tested independently from<br>
the toposort patch?<br></blockquote><div><br></div><div>I tested them myself for a couple of days, and they are present in the github repo, which has been used by several people to build and test jack1.<br></div><br></div><div class="gmail_quote">My original plan was to compare the .o files generated before and after uncrustify, but I realized that this is not so simple. <br></div><div class="gmail_quote"><br></div></div></div>