[llvm-dev] "Living Downstream Without Drowning" BOF @ Dev Meeting

[Bruce Hoult via llvm-dev]

On Thu, Nov 5, 2015 at 12:18 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> 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.


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.


>   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


I presume you did a build and ran tests at each node? Simple git merges
won't take long at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/0d9068d7/attachment-0001.html>