<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 5, 2015 at 12:18 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  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</blockquote><div><br></div><div>I presume you did a build and ran tests at each node? Simple git merges won't take long at all.</div><div><br></div></div></div></div>