Parallel Execution of Full IMerge

[make1980-zz]

Currently when generating the merge mesh using full imerge we sequentially do incremental merge. This causes the process to be really long if we have a lot of commits to merge from two forked branches.

Ideally the merge can be done using multiple threads on all the commits along the diagonal line like this:

o - 0 - 1 - 2    ← master
    |   |     
    A - A1   => thread 1 working on A2
    |            
    B    => thread 2 working on B1 
    ↑
   v1.0

We plan to implement this - any thoughts? @mhagger

[mhagger]

I expect that this would be helpful to people using full imerge. Personally, I don't use that mode, partly because it takes so long and partly because the full mesh is usually not needed.

See #66 for some other discussion of speed and parallelism, though mostly regarding the bisection algorithm, not the full mesh.

Currently, the merges are done in the working copy that the imerge was started in, and since there is only one such working copy, only one merge can be done at a time. How do you plan to get around that? I didn't think that Git was capable of doing merges without affecting the working copy or main index. An alternative would be to use worktrees, though for a big repository they would be somewhat expensive to set up.

I know that libgit2 can do merges without touching the working copy; that would be another alternative. See #109 for related info.

It will also be a little bit tricky to ask the user to intervene if there is a conflict. Presumably you would want to recreate any conflict in the working tree and ask the user to resolve it there?