Re: [PATCH 0/2] A new merge algorithm, take 3

[A Large Angry SCM <gitzilla@gmail.com>]

Junio C Hamano wrote:
[...]
> Subject: [PATCH] Multi-backend merge driver.
> 
> This is just an illustration of concept patch.
> 
> The new command 'git merge' takes the current head and one or more
> remote heads, with the commit log message for the automated case.
> 
> If the heads being merged are simple fast-forwards, it acts the
> same way as the current 'git resolve'.  Otherwise, it tries
> different merge strategies and takes the result from the one that
> succeeded auto-merging, if there is any.
> 
> If no merge strategy succeeds auto-merging, their results are
> evaluated for number of paths needed for hand resolving, and the
> one with the least number of such paths is left in the working
> tree.  The user is asked to resolve them by hand and make a
> commit manually.
[...]

This last paragraph concerns me because it limits us to a very simple 
metric, "number of paths needed for hand resolving". Some "hand 
resolving" situations can be more complex than others and it would nice 
to use that information if it was available.

Of course I have no idea what that information may be or how it can be 
computed.