Thanks a lot for the explanations Brian and Hannes. That clarifies it a lot. I had not come across such a semantic issue in my limited experience with git before, so I was a bit thrown off. Given this behavior, I still think it would be a great feature for the person doing the merge to at least optionally be able to see highlighted parts of the code that had any changes between the base and the other two branches. Since these parts of the code could potentially cause problems much more than lines of code that have not been touched by any branch. But I guess that would be more a GUI feature than related to git directly, correct? Maybe there is already a GUI offering that? On Sat, 16 Mar 2024 at 00:29, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Johannes Sixt <j6t@xxxxxxxx> writes: > > > That's the responsibility of the person doing the merge, who at best > > understands both branches being merged.[*] It is of utmost importance > > that a merge result produced by Git is not taken without thinking. It is > > never a no-brainer. > > > > [*] That is where good commit messages shine. > > I am glad that some folks appreciate what I do every day ;-)
