Re: Git is not recognizing some merge conflicts and just accepting incoming master version

From: Johannes Sixt <j6t@kdbg.org>
Date: Mar 15, 2024, 22:19 UTC
Message-ID: <ebd073ef-4ba4-44df-919a-2adefb40e3e7@kdbg.org>
In-Reply-To: <CA+XMOBskofgsmCbcchmPYo9rF9+Cdtdj_m8VzQrLbGhZPm+mrw@mail.gmail.com>

Am 15.03.24 um 14:22 schrieb Kai:

Show 5 quoted lines

> If this is expected behavior, this is a big issue in this case, as I
> cannot trust that after sorting all conflicts that my code will work.
> In that case I would need to manually review every diff. Or is there
> maybe a stricter mode for merge conflicts, to also highlight these
> types of differences?

Brian has already explained that the result is the expected one. For Git, the text is just lines of text and that's all it cares about. But for us (and the systems that use the texts, compilers, web servers...) they are much more than that: they carry meaning. Git doesn't care about the meaning.

It is correct to some degree that you cannot trust the result of a merge. It will be correct on the line-of-text-basis, but it is not necessarily correct when it comes to the meaning of the text.

Yes, you have to manually review every (not diff, but) merge result. 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.

-- Hannes