Am 11.06.21 um 08:43 schrieb Junio C Hamano: > Johannes Sixt <j6t@xxxxxxxx> writes: > >> 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. > > "rebase -i" to reorganize one's own series would be a prime example > of "conflicts you need to resolve in code that is purely your own > and nobody else's", and cherry-picking used while reorganizing one's > own series falls into the same category. I agree that a simpler > markup would be more appropriate in such cases. > > Rebasing to catch up with updated upstream is a different story, > though. The same for cherry-picking an earlier change to an updated > upstream. I've reflected on this a bit more as well. I've forgotten about the "catch up with someone else" case. That is certainly helped by diff3 style. I retract my opposition and am now neutral to a potential change of default. (I still don't endorse it because it upsets my workflow.) The case that inner conflicts are presented sub-optimally under diff3 remains, though. -- Hannes
