Am 11.06.21 um 03:20 schrieb Junio C Hamano: > Yes, it does not help that the given sample involves conflicts in > the inner merge, which is unfortunately almost unreadable. For less > confusing merges, diff3 style is often a lifesaver necessary for > avoiding mismerges by showing what the common ancestor looked like, > so that the reader/merger/integrator can tell what each side wanted > to do to the conflicted section. > > Rejecting diff3 style output because of the way a conflicted part in > the inner merge appears as a common ancestor version may be throwing > the baby out with the bathwater. A different way to say it is that > until we improve the way the conflicted inner merge is shown, diff3 > style is not something we can recommend to new users as a default, I > would think. I understand that diff3 is very useful for an integrator like you who does a lot of merges of code that was not written by yourself. But I would estimate that most conflicts (in absolute number among all developers using Git) arise during rebase operations and cherry-picking, i.e., while one is working on their own code. In such sitations, the simpler conflict markup is sufficient, because one knows the background and reason of the conflicts. And then the ability to compact conflicts is a life-saver. Therefore, I argue that simple conflict style should remain the default even if the presentation of inner conflicts under diff3 style is improved. -- Hannes
