Show 16 quoted lines
> On Sat, 30 Dec 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>>> Of course, you can hit mismerges like the illustrated one _without_
>>> being marked as conflict (e.g. if the chunk of identical code is _not_
>>> added, but only the increments), but we should at least avoid them
>>> where possible.
>>
>> Perhaps you could make it even more conservating merge conflicts option
>> (to tighten merge conflicts even more) to xdl_merge, but not used by
>> default because as it removes accidental conflicts it increases
>> mismerges (falsely not conflicted).
>
> There is no way to do this sanely. If you want to catch these mismerges,
> you have to mark _all_ modifications as conflicting.
Currently you have:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
I was thinking about:
- If you set level to 3, if one part after overlapping changes analysis
in level 2 has empty conflict region, resolve this conflict as second
side. WARNING: this reduces number of merge conflicts, but might give
mismerges!
Or something like that.
Jakub Narebski <jnareb@gmail.com>