<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 4:24 AM, David Chisnall via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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 5 Nov 2015, at 12:20, Bruce Hoult <<a href="mailto:bruce@hoult.org">bruce@hoult.org</a>> wrote:<br>
><br>
> On Thu, Nov 5, 2015 at 12:18 PM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
>> Thank you very much for the recommendation!  The down side of git-imerge is that it is O(NM), where N is the number of your commits since the last merge and M is the number of upstream commits.<br>
><br>
> Often it should be a lot less than O(NM), due to the bisection strategy, but if there are a lot of merge conflicts then it can be more.<br>
<br>
</span>The ‘autofilling’ was what took most time, and it autofills the merge of every pair of (upstream, local) commits.<br>
<span class=""><br>
>>   I just finished a merge of about 6 months with 4000 upstream commits and a bit over 100 local ones - it took about a week of CPU time.  The huge up side is that it took a lot less human time than previous merges<br>
><br>
> I presume you did a build and ran tests at each node? Simple git merges won't take long at all.<br>
<br>
</span>Nope.  Unfortunately, you can’t git-imerge clang and LLVM simultaneously, and the lack of API stability in LLVM meant that there was no way of building my tree until I’d finished merging both.  I’m not sure if this is something that can be fixed by using git submodules for the tools in the svn exports in some automatic way.<br></blockquote><div><br></div><div>I believe Takumi deals with this by having a single llvm-project git mirror and using the "out of tree" build support so he can build directly in that tree without having to move/checkout clang into tools/clang, etc, etc. & he uses this for lock-step bisecting. Of course doesn't work perfectly because most of the rest of us don't use atomic commits to make those API breaking changes because it isn't better/more easily supported... </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>