On Sun, 31 Dec 2006, Johannes Schindelin wrote: > 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 Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html