Re: Merge-Recursive Improvements

Johannes Sixt [off-list ref] writes:

Voltage Spike schrieb:

quoted

Third, git doesn't appear to have any sense of context when performing a
merge. Another contrived example which wouldn't be flagged as a merge
conflict:

  ptr = malloc(len); // Added in HEAD.
  init();            // Included in merge-base.
  ptr = malloc(len); // Added in "merge".

You seem to say that you want this to result in a merge conflict.

I'm opposed to this: It means that you would mark a conflict if there is a
single unchanged line between the two changes that come from the merged
branches. So far it has happened for me much more frequently that such
merges were correct, and I should not be bothered with conflict markers. I
conciously prefer to pay the price that such a merge is incorrect on occasion.

Actually I think we really should mark this as conflict.  The
tool should resolve only the most unquestionable cases and keep
humans in the loop to validate the result if there is any
uncertainty.  Resolving the above example automatically without
warning is most likely a problem waiting to happen.

Such a merge being more often correct than not is not an
argument for resolving them silently.  It's rare mismerge cases
that will bite you later, and we should really be careful,
especially when a mismerge is less common.