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

[David Chisnall via llvm-dev]

On 5 Nov 2015, at 12:20, Bruce Hoult <bruce at hoult.org> wrote:
> 
> 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.

The ‘autofilling’ was what took most time, and it autofills the merge of every pair of (upstream, local) commits.

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

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.

David