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

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

[Kai]

I am encountering strange behavior when trying to merge master into a
feature branch. Trying with guis VScode and Gitkraken, both are not
displaying all conflicts in the files correctly and are just accepting
some changes from master which are conflicts and break the code.

I am including two example files as well as screenshots.

In the first example, the conflict of the UseFormReturn type changing
between the two versions of the file is not being recognized.

In the second example the useForm hook is completely different between
master and the feature branch called hook-form, but no conflict is
displayed.

Besides trying to merge the code in VScode and Gitkraken to rule out
an issue with the editor, I also installed Git-2.41.0.3-64-bit.exe to
make sure it is not a problem with Git-2.44.0-64-bit.exe I was using.

I am quite confused because this seems like a major issue that would
not have gone unnoticed so long, but I also don't see what I could be
doing wrong.

Ayn support would be much appreciated.

Example and screenshots:
https://drive.google.com/file/d/1rUaoA1rCYFzaEYeQldTupinQde-AyRjv/view?usp=sharing

VSCode used:
Version: 1.87.2 (user setup)
Commit: 863d258
Datum: 2024-03-08T15:20:17.278Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
Betriebssystem: Windows_NT x64 10.0.22631

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

[Johannes Sixt]

Am 14.03.24 um 11:30 schrieb Kai:
> I am encountering strange behavior when trying to merge master into a
> feature branch. Trying with guis VScode and Gitkraken, both are not
> displaying all conflicts in the files correctly and are just accepting
> some changes from master which are conflicts and break the code.
> 
> I am including two example files as well as screenshots.

No files were included in this message. Don't post screenshots when the
content can also be represented as text.

That said, a conflict needs three files, not two: the base version,
their version, and our version. But better than file attachments would
be to just paste the relevant parts into the message (if you know what
the relevant parts are and that other parts are not relevant).

> In the first example, the conflict of the UseFormReturn type changing
> between the two versions of the file is not being recognized.
> 
> In the second example the useForm hook is completely different between
> master and the feature branch called hook-form, but no conflict is
> displayed.

These descriptions sound like the conflicts are of semantic kind. Git
can't help in such cases. Git can only detect textual conflicts, that
is, when both sides modify the same or adjacent lines of code in
different ways.

-- Hannes

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

[Kai]

Hi Hannes,

Thank you for having a look. Below my responses and further information:

On Fri, 15 Mar 2024 at 09:24, Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 14.03.24 um 11:30 schrieb Kai:
> > I am encountering strange behavior when trying to merge master into a
> > feature branch. Trying with guis VScode and Gitkraken, both are not
> > displaying all conflicts in the files correctly and are just accepting
> > some changes from master which are conflicts and break the code.
> >
> > I am including two example files as well as screenshots.
>
> No files were included in this message. Don't post screenshots when the
> content can also be represented as text.
>
> That said, a conflict needs three files, not two: the base version,
> their version, and our version. But better than file attachments would
> be to just paste the relevant parts into the message (if you know what
> the relevant parts are and that other parts are not relevant).

Ok, I was assuming that having the whole files may be better to
reproduce the problem, but if just the relevant parts are enough, let
me do that.

Here is an example from all three files:

### BASE FILE (I used git merge-base master hook-form to show the
ancestor commit)
export const AddListingForm = (active: number) => {


  const form = useForm({

    defaultValues: {
      city: { name: '', lat: 0, lon: 0 },
      neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },



### MASTER BRANCH (THEIR VERSION):
export const AddListingForm = (active: number) => {
  const form = useForm({
    name: "add-listing-form",
    initialValues: {
      city: { name: "", lat: 0, lon: 0 },
      neighborhood: { name: "", lat: 0, lon: 0, neighborhood: "" },



### HOOK-FORM BRANCH (OUR VERSION):
export const AddListingForm = (active: number) => {


  const form = useForm({

    defaultValues: {
      city: { name: '', lat: 0, lon: 0 },
      neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },


### GIT DIFF MASTER TO BASE FILE (git diff
12545fa846fb0d042a4ed29ee0699d89f1621bc2 master --
components/add-listing/forms/AddListingForm.ts)
   const form = useForm({
-
-    defaultValues: {
-      city: { name: '', lat: 0, lon: 0 },
-      neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
+    name: "add-listing-form",
+    initialValues: {

### GIT DIFF BASE FILE TO HOOK-FORM (git diff
12545fa846fb0d042a4ed29ee0699d89f1621bc2 hook-form --
components/add-listing/forms/AddListingForm.ts)
No diff in relevant part


So as you can see, in this case Master has changes to the base file at
the relevant part, while in the hook form branch we continued to use
the base file version of that part. Now maybe I misunderstand how
merge conflicts are supposed to work, but shouldn't I expect git
marking the changes master made as a conflict? Because in master parts
of the file were changed that I did not change in the new branch? When
I now merge, the code is not working, because masters code is applied
and it breaks other parts of the code in the same file.

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?

>
> > In the first example, the conflict of the UseFormReturn type changing
> > between the two versions of the file is not being recognized.
> >
> > In the second example the useForm hook is completely different between
> > master and the feature branch called hook-form, but no conflict is
> > displayed.
>
> These descriptions sound like the conflicts are of semantic kind. Git
> can't help in such cases. Git can only detect textual conflicts, that
> is, when both sides modify the same or adjacent lines of code in
> different ways.
>
> -- Hannes
>

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]

On 2024-03-15 at 13:22:52, Kai wrote:
> Ok, I was assuming that having the whole files may be better to
> reproduce the problem, but if just the relevant parts are enough, let
> me do that.
> 
> Here is an example from all three files:
> 
> ### BASE FILE (I used git merge-base master hook-form to show the
> ancestor commit)
> export const AddListingForm = (active: number) => {
> 
> 
>   const form = useForm({
> 
>     defaultValues: {
>       city: { name: '', lat: 0, lon: 0 },
>       neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
> 
> 
> 
> ### MASTER BRANCH (THEIR VERSION):
> export const AddListingForm = (active: number) => {
>   const form = useForm({
>     name: "add-listing-form",
>     initialValues: {
>       city: { name: "", lat: 0, lon: 0 },
>       neighborhood: { name: "", lat: 0, lon: 0, neighborhood: "" },
> 
> 
> 
> ### HOOK-FORM BRANCH (OUR VERSION):
> export const AddListingForm = (active: number) => {
> 
> 
>   const form = useForm({
> 
>     defaultValues: {
>       city: { name: '', lat: 0, lon: 0 },
>       neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
> 
> 
> ### GIT DIFF MASTER TO BASE FILE (git diff
> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 master --
> components/add-listing/forms/AddListingForm.ts)
>    const form = useForm({
> -
> -    defaultValues: {
> -      city: { name: '', lat: 0, lon: 0 },
> -      neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },
> +    name: "add-listing-form",
> +    initialValues: {
> 
> ### GIT DIFF BASE FILE TO HOOK-FORM (git diff
> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 hook-form --
> components/add-listing/forms/AddListingForm.ts)
> No diff in relevant part
> 
> 
> So as you can see, in this case Master has changes to the base file at
> the relevant part, while in the hook form branch we continued to use
> the base file version of that part. Now maybe I misunderstand how
> merge conflicts are supposed to work, but shouldn't I expect git
> marking the changes master made as a conflict? Because in master parts
> of the file were changed that I did not change in the new branch? When
> I now merge, the code is not working, because masters code is applied
> and it breaks other parts of the code in the same file.

I think you may misunderstand how a three-way merge works.  Git
considers exactly three points: the merge base and the two heads.  If,
in a particular region of code, there is a difference between the merge
base and one of the heads, and no difference between the merge base and
the other head, then Git adopts the difference.  This is the fundamental
idea of a three-way merge: to include the changes made from both sides.

This is true even if the side that has no changes between the merge base
and one of the heads has had multiple changes and reverts in between.
The intermediate states of the two branches are not considered.

It is also irrelevant what happens to other parts of the file as long as
they are not directly adjacent to the parts that the merge is working
on.

So in this case, it looks like Git is functioning as expected.

> 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?

This is called a semantic conflict, and it can occur.  Git typically
operates on lines for diffs and merges, and that doesn't intrinsically
line up with functional units of code, as you've seen.  It's possible
that a three-way merge produces broken or even syntactically invalid
code.

This is why you need tests, so that people can run the tests on the
merged value and verify that the result is functional.  Usually this can
be done via a CI system.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Johannes Sixt]

Am 15.03.24 um 14:22 schrieb Kai:
> 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

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

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> 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 ;-)

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

[Kai]

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@pobox.com> wrote:
>
> Johannes Sixt <j6t@kdbg.org> 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 ;-)

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

[Thomas Guyot]

On 2024-03-16 05:19, Kai wrote:
> 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?

The --diff-merges=combined option (or simply "-c") of git show is 
probably what you're looking for.

There is also a dense-combined (or "--cc") option that skips seemingly 
unrelated hunks, which doesn't mean these hunk aren't problematic, just 
that there's 6+ lines appart.

Regards,

--
Thomas