{"thread":{"id":"61119","subject":"Git is not recognizing some merge conflicts and just accepting incoming master version","startedAt":"2024-03-14T10:30:44Z","lastAt":"2024-03-23T19:17:25Z","messageCount":8,"participants":["Kai","Johannes Sixt","brian m. carlson","Junio C Hamano","Thomas Guyot"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490616","messageId":"CA+XMOBuK1_BNqgQRfCne8dVXKGPt+iQ9wt4iZqz0PgEqZ5UCtg@mail.gmail.com","threadId":"61119","inReplyTo":null,"subject":"Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Kai","fromEmail":"k.vongrambusch@googlemail.com","sentAt":"2024-03-14T10:30:32Z","receivedAt":"2024-03-14T10:30:44Z","isPatch":false,"sender":{"key":"k.vongrambusch@googlemail.com","avatar":null},"body":"I am encountering strange behavior when trying to merge master into a\nfeature branch. Trying with guis VScode and Gitkraken, both are not\ndisplaying all conflicts in the files correctly and are just accepting\nsome changes from master which are conflicts and break the code.\n\nI am including two example files as well as screenshots.\n\nIn the first example, the conflict of the UseFormReturn type changing\nbetween the two versions of the file is not being recognized.\n\nIn the second example the useForm hook is completely different between\nmaster and the feature branch called hook-form, but no conflict is\ndisplayed.\n\nBesides trying to merge the code in VScode and Gitkraken to rule out\nan issue with the editor, I also installed Git-2.41.0.3-64-bit.exe to\nmake sure it is not a problem with Git-2.44.0-64-bit.exe I was using.\n\nI am quite confused because this seems like a major issue that would\nnot have gone unnoticed so long, but I also don't see what I could be\ndoing wrong.\n\nAyn support would be much appreciated.\n\nExample and screenshots:\nhttps://drive.google.com/file/d/1rUaoA1rCYFzaEYeQldTupinQde-AyRjv/view?usp=sharing\n\nVSCode used:\nVersion: 1.87.2 (user setup)\nCommit: 863d258\nDatum: 2024-03-08T15:20:17.278Z\nElectron: 27.3.2\nElectronBuildId: 26836302\nChromium: 118.0.5993.159\nNode.js: 18.17.1\nV8: 11.8.172.18-electron.0\nBetriebssystem: Windows_NT x64 10.0.22631\n"},{"id":"490679","messageId":"606fe3fa-a5a0-4d35-a4a0-59521043dde4@kdbg.org","threadId":"61119","inReplyTo":"CA+XMOBuK1_BNqgQRfCne8dVXKGPt+iQ9wt4iZqz0PgEqZ5UCtg@mail.gmail.com","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-03-15T07:24:27Z","receivedAt":"2024-03-15T08:14:40Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 14.03.24 um 11:30 schrieb Kai:\n> I am encountering strange behavior when trying to merge master into a\n> feature branch. Trying with guis VScode and Gitkraken, both are not\n> displaying all conflicts in the files correctly and are just accepting\n> some changes from master which are conflicts and break the code.\n> \n> I am including two example files as well as screenshots.\n\nNo files were included in this message. Don't post screenshots when the\ncontent can also be represented as text.\n\nThat said, a conflict needs three files, not two: the base version,\ntheir version, and our version. But better than file attachments would\nbe to just paste the relevant parts into the message (if you know what\nthe relevant parts are and that other parts are not relevant).\n\n> In the first example, the conflict of the UseFormReturn type changing\n> between the two versions of the file is not being recognized.\n> \n> In the second example the useForm hook is completely different between\n> master and the feature branch called hook-form, but no conflict is\n> displayed.\n\nThese descriptions sound like the conflicts are of semantic kind. Git\ncan't help in such cases. Git can only detect textual conflicts, that\nis, when both sides modify the same or adjacent lines of code in\ndifferent ways.\n\n-- Hannes\n\n"},{"id":"490688","messageId":"CA+XMOBskofgsmCbcchmPYo9rF9+Cdtdj_m8VzQrLbGhZPm+mrw@mail.gmail.com","threadId":"61119","inReplyTo":"606fe3fa-a5a0-4d35-a4a0-59521043dde4@kdbg.org","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Kai","fromEmail":"k.vongrambusch@googlemail.com","sentAt":"2024-03-15T13:22:52Z","receivedAt":"2024-03-15T13:23:07Z","isPatch":false,"sender":{"key":"k.vongrambusch@googlemail.com","avatar":null},"body":"Hi Hannes,\n\nThank you for having a look. Below my responses and further information:\n\nOn Fri, 15 Mar 2024 at 09:24, Johannes Sixt wrote:\n>\n> Am 14.03.24 um 11:30 schrieb Kai:\n> > I am encountering strange behavior when trying to merge master into a\n> > feature branch. Trying with guis VScode and Gitkraken, both are not\n> > displaying all conflicts in the files correctly and are just accepting\n> > some changes from master which are conflicts and break the code.\n> >\n> > I am including two example files as well as screenshots.\n>\n> No files were included in this message. Don't post screenshots when the\n> content can also be represented as text.\n>\n> That said, a conflict needs three files, not two: the base version,\n> their version, and our version. But better than file attachments would\n> be to just paste the relevant parts into the message (if you know what\n> the relevant parts are and that other parts are not relevant).\n\nOk, I was assuming that having the whole files may be better to\nreproduce the problem, but if just the relevant parts are enough, let\nme do that.\n\nHere is an example from all three files:\n\n### BASE FILE (I used git merge-base master hook-form to show the\nancestor commit)\nexport const AddListingForm = (active: number) => {\n\n\n const form = useForm({\n\n defaultValues: {\n city: { name: '', lat: 0, lon: 0 },\n neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n\n\n\n### MASTER BRANCH (THEIR VERSION):\nexport const AddListingForm = (active: number) => {\n const form = useForm({\n name: \"add-listing-form\",\n initialValues: {\n city: { name: \"\", lat: 0, lon: 0 },\n neighborhood: { name: \"\", lat: 0, lon: 0, neighborhood: \"\" },\n\n\n\n### HOOK-FORM BRANCH (OUR VERSION):\nexport const AddListingForm = (active: number) => {\n\n\n const form = useForm({\n\n defaultValues: {\n city: { name: '', lat: 0, lon: 0 },\n neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n\n\n### GIT DIFF MASTER TO BASE FILE (git diff\n12545fa846fb0d042a4ed29ee0699d89f1621bc2 master --\ncomponents/add-listing/forms/AddListingForm.ts)\n const form = useForm({\n-\n- defaultValues: {\n- city: { name: '', lat: 0, lon: 0 },\n- neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n+ name: \"add-listing-form\",\n+ initialValues: {\n\n### GIT DIFF BASE FILE TO HOOK-FORM (git diff\n12545fa846fb0d042a4ed29ee0699d89f1621bc2 hook-form --\ncomponents/add-listing/forms/AddListingForm.ts)\nNo diff in relevant part\n\n\nSo as you can see, in this case Master has changes to the base file at\nthe relevant part, while in the hook form branch we continued to use\nthe base file version of that part. Now maybe I misunderstand how\nmerge conflicts are supposed to work, but shouldn't I expect git\nmarking the changes master made as a conflict? Because in master parts\nof the file were changed that I did not change in the new branch? When\nI now merge, the code is not working, because masters code is applied\nand it breaks other parts of the code in the same file.\n\nIf this is expected behavior, this is a big issue in this case, as I\ncannot trust that after sorting all conflicts that my code will work.\nIn that case I would need to manually review every diff. Or is there\nmaybe a stricter mode for merge conflicts, to also highlight these\ntypes of differences?\n\n>\n> > In the first example, the conflict of the UseFormReturn type changing\n> > between the two versions of the file is not being recognized.\n> >\n> > In the second example the useForm hook is completely different between\n> > master and the feature branch called hook-form, but no conflict is\n> > displayed.\n>\n> These descriptions sound like the conflicts are of semantic kind. Git\n> can't help in such cases. Git can only detect textual conflicts, that\n> is, when both sides modify the same or adjacent lines of code in\n> different ways.\n>\n> -- Hannes\n>\n"},{"id":"490740","messageId":"ZfTB7NNtyYzv_6-t@tapette.crustytoothpaste.net","threadId":"61119","inReplyTo":"CA+XMOBskofgsmCbcchmPYo9rF9+Cdtdj_m8VzQrLbGhZPm+mrw@mail.gmail.com","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-03-15T21:47:24Z","receivedAt":"2024-03-15T21:47:32Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-03-15 at 13:22:52, Kai wrote:\n> Ok, I was assuming that having the whole files may be better to\n> reproduce the problem, but if just the relevant parts are enough, let\n> me do that.\n> \n> Here is an example from all three files:\n> \n> ### BASE FILE (I used git merge-base master hook-form to show the\n> ancestor commit)\n> export const AddListingForm = (active: number) => {\n> \n> \n> const form = useForm({\n> \n> defaultValues: {\n> city: { name: '', lat: 0, lon: 0 },\n> neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n> \n> \n> \n> ### MASTER BRANCH (THEIR VERSION):\n> export const AddListingForm = (active: number) => {\n> const form = useForm({\n> name: \"add-listing-form\",\n> initialValues: {\n> city: { name: \"\", lat: 0, lon: 0 },\n> neighborhood: { name: \"\", lat: 0, lon: 0, neighborhood: \"\" },\n> \n> \n> \n> ### HOOK-FORM BRANCH (OUR VERSION):\n> export const AddListingForm = (active: number) => {\n> \n> \n> const form = useForm({\n> \n> defaultValues: {\n> city: { name: '', lat: 0, lon: 0 },\n> neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n> \n> \n> ### GIT DIFF MASTER TO BASE FILE (git diff\n> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 master --\n> components/add-listing/forms/AddListingForm.ts)\n> const form = useForm({\n> -\n> - defaultValues: {\n> - city: { name: '', lat: 0, lon: 0 },\n> - neighborhood: { name: '', lat: 0, lon: 0, neighborhood: '' },\n> + name: \"add-listing-form\",\n> + initialValues: {\n> \n> ### GIT DIFF BASE FILE TO HOOK-FORM (git diff\n> 12545fa846fb0d042a4ed29ee0699d89f1621bc2 hook-form --\n> components/add-listing/forms/AddListingForm.ts)\n> No diff in relevant part\n> \n> \n> So as you can see, in this case Master has changes to the base file at\n> the relevant part, while in the hook form branch we continued to use\n> the base file version of that part. Now maybe I misunderstand how\n> merge conflicts are supposed to work, but shouldn't I expect git\n> marking the changes master made as a conflict? Because in master parts\n> of the file were changed that I did not change in the new branch? When\n> I now merge, the code is not working, because masters code is applied\n> and it breaks other parts of the code in the same file.\n\nI think you may misunderstand how a three-way merge works. Git\nconsiders exactly three points: the merge base and the two heads. If,\nin a particular region of code, there is a difference between the merge\nbase and one of the heads, and no difference between the merge base and\nthe other head, then Git adopts the difference. This is the fundamental\nidea of a three-way merge: to include the changes made from both sides.\n\nThis is true even if the side that has no changes between the merge base\nand one of the heads has had multiple changes and reverts in between.\nThe intermediate states of the two branches are not considered.\n\nIt is also irrelevant what happens to other parts of the file as long as\nthey are not directly adjacent to the parts that the merge is working\non.\n\nSo in this case, it looks like Git is functioning as expected.\n\n> If this is expected behavior, this is a big issue in this case, as I\n> cannot trust that after sorting all conflicts that my code will work.\n> In that case I would need to manually review every diff. Or is there\n> maybe a stricter mode for merge conflicts, to also highlight these\n> types of differences?\n\nThis is called a semantic conflict, and it can occur. Git typically\noperates on lines for diffs and merges, and that doesn't intrinsically\nline up with functional units of code, as you've seen. It's possible\nthat a three-way merge produces broken or even syntactically invalid\ncode.\n\nThis is why you need tests, so that people can run the tests on the\nmerged value and verify that the result is functional. Usually this can\nbe done via a CI system.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"490742","messageId":"ebd073ef-4ba4-44df-919a-2adefb40e3e7@kdbg.org","threadId":"61119","inReplyTo":"CA+XMOBskofgsmCbcchmPYo9rF9+Cdtdj_m8VzQrLbGhZPm+mrw@mail.gmail.com","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-03-15T22:19:16Z","receivedAt":"2024-03-15T22:19:18Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.03.24 um 14:22 schrieb Kai:\n> If this is expected behavior, this is a big issue in this case, as I\n> cannot trust that after sorting all conflicts that my code will work.\n> In that case I would need to manually review every diff. Or is there\n> maybe a stricter mode for merge conflicts, to also highlight these\n> types of differences?\n\nBrian has already explained that the result is the expected one. For\nGit, the text is just lines of text and that's all it cares about. But\nfor us (and the systems that use the texts, compilers, web servers...)\nthey are much more than that: they carry meaning. Git doesn't care about\nthe meaning.\n\nIt is correct to some degree that you cannot trust the result of a\nmerge. It will be correct on the line-of-text-basis, but it is not\nnecessarily correct when it comes to the meaning of the text.\n\nYes, you have to manually review every (not diff, but) merge result.\nThat's the responsibility of the person doing the merge, who at best\nunderstands both branches being merged.[*] It is of utmost importance\nthat a merge result produced by Git is not taken without thinking. It is\nnever a no-brainer.\n\n[*] That is where good commit messages shine.\n\n-- Hannes\n\n"},{"id":"490744","messageId":"xmqqzfuznn7g.fsf@gitster.g","threadId":"61119","inReplyTo":"ebd073ef-4ba4-44df-919a-2adefb40e3e7@kdbg.org","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-15T22:29:23Z","receivedAt":"2024-03-15T22:29:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> That's the responsibility of the person doing the merge, who at best\n> understands both branches being merged.[*] It is of utmost importance\n> that a merge result produced by Git is not taken without thinking. It is\n> never a no-brainer.\n>\n> [*] That is where good commit messages shine.\n\nI am glad that some folks appreciate what I do every day ;-)\n"},{"id":"490775","messageId":"CA+XMOBuYVWwEE-p=3GHBUcnnM_jn0pneW1rbcQU124DjnJYycA@mail.gmail.com","threadId":"61119","inReplyTo":"xmqqzfuznn7g.fsf@gitster.g","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Kai","fromEmail":"k.vongrambusch@googlemail.com","sentAt":"2024-03-16T09:19:48Z","receivedAt":"2024-03-16T09:20:01Z","isPatch":false,"sender":{"key":"k.vongrambusch@googlemail.com","avatar":null},"body":"Thanks a lot for the explanations Brian and Hannes. That clarifies it\na lot. I had not come across such a semantic issue in my limited\nexperience with git before, so I was a bit thrown off.\n\nGiven this behavior, I still think it would be a great feature for the\nperson doing the merge to at least optionally be able to see\nhighlighted parts of the code that had any changes between the base\nand the other two branches. Since these parts of the code could\npotentially cause problems much more than lines of code that have not\nbeen touched by any branch. But I guess that would be more a GUI\nfeature than related to git directly, correct? Maybe there is already\na GUI offering that?\n\n\nOn Sat, 16 Mar 2024 at 00:29, Junio C Hamano wrote:\n>\n> Johannes Sixt writes:\n>\n> > That's the responsibility of the person doing the merge, who at best\n> > understands both branches being merged.[*] It is of utmost importance\n> > that a merge result produced by Git is not taken without thinking. It is\n> > never a no-brainer.\n> >\n> > [*] That is where good commit messages shine.\n>\n> I am glad that some folks appreciate what I do every day ;-)\n"},{"id":"491311","messageId":"d8fa6ab2-949b-4d6f-9c8f-e80f2e524fb7@gmail.com","threadId":"61119","inReplyTo":"CA+XMOBuYVWwEE-p=3GHBUcnnM_jn0pneW1rbcQU124DjnJYycA@mail.gmail.com","subject":"Re: Git is not recognizing some merge conflicts and just accepting incoming master version","fromName":"Thomas Guyot","fromEmail":"tguyot@gmail.com","sentAt":"2024-03-23T19:17:20Z","receivedAt":"2024-03-23T19:17:25Z","isPatch":false,"sender":{"key":"tguyot@gmail.com","avatar":"https://avatars.githubusercontent.com/u/403890?v=4"},"body":"On 2024-03-16 05:19, Kai wrote:\n> Thanks a lot for the explanations Brian and Hannes. That clarifies it\n> a lot. I had not come across such a semantic issue in my limited\n> experience with git before, so I was a bit thrown off.\n>\n> Given this behavior, I still think it would be a great feature for the\n> person doing the merge to at least optionally be able to see\n> highlighted parts of the code that had any changes between the base\n> and the other two branches. Since these parts of the code could\n> potentially cause problems much more than lines of code that have not\n> been touched by any branch. But I guess that would be more a GUI\n> feature than related to git directly, correct? Maybe there is already\n> a GUI offering that?\n\nThe --diff-merges=combined option (or simply \"-c\") of git show is \nprobably what you're looking for.\n\nThere is also a dense-combined (or \"--cc\") option that skips seemingly \nunrelated hunks, which doesn't mean these hunk aren't problematic, just \nthat there's 6+ lines appart.\n\nRegards,\n\n--\nThomas\n"}]}