{"thread":{"id":"44974","subject":"Force Confirmation for Dropping Changed Lines","startedAt":"2017-01-25T22:16:51Z","lastAt":"2017-01-26T20:57:32Z","messageCount":11,"participants":["Hilco Wijbenga","Jacob Keller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310239","messageId":"CAE1pOi2YZayEfKxxh3gsTds1mQ9L1E9AW=wPnmW=Dg=-EMj=tw@mail.gmail.com","threadId":"44974","inReplyTo":null,"subject":"Force Confirmation for Dropping Changed Lines","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2017-01-25T22:16:04Z","receivedAt":"2017-01-25T22:16:51Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi all,\n\nMost of the time, when a later commit changes a line in an identical\nfashion during, say, a rebase, you want Git to silently continue by\ndropping the duplicate change from the later commit. I have a common\n(for me) scenario where I want Git to specifically ask me to resolve\nthis \"conflict\" myself instead of simply assuming that the change has\nalready been applied.\n\nLet's say I have a file my-code.x that starts with a line indicating\nits version:\n\n===== my-code.x =====\nVERSION=1.2\nline 1\nline 2\nline 3\n=====\n\nIn my branch my-branch off of master, I make a change:\n\n===== my-code.x =====\nVERSION=1.3\nline 1\nline 2\nline 2a\nline 3\n=====\n\nNow someone else makes a different change on master and pushes it ([1]):\n\n===== my-code.x =====\nVERSION=1.3\nline 1\nline 2\nline 3\nline 4\n=====\n\nWhen I rebase my-branch onto origin/master, I get no conflicts and\neverything seems fine ([2]):\n\n===== my-code.x =====\nVERSION=1.3\nline 1\nline 2\nline 2a\nline 3\nline 4\n=====\n\nExcept that I should have used VERSION=1.4, not VERSION=1.3 because I\nmade a change to my-code.x. Obviously, for a single file this is easy\nto remember/check but when it's hidden among lots of files and commits\nit becomes very hard to find these types of errors.\n\nHow can I force Git to not assume my change to the first line is \"redundant\"?\n\nCheers,\nHilco\n\n[1] Note that this someone is (correctly) using the same, new version of 1.3.\n[2] If my example is actually incorrect, then please just pretend\nthere are no conflicts.\n"},{"id":"310241","messageId":"CA+P7+xrupLuYAj7tn_1EaUiN6eaCmtgX-_d4mnByDq95cuqiWQ@mail.gmail.com","threadId":"44974","inReplyTo":"CAE1pOi2YZayEfKxxh3gsTds1mQ9L1E9AW=wPnmW=Dg=-EMj=tw@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-25T22:24:39Z","receivedAt":"2017-01-25T22:25:10Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga\n wrote:\n> How can I force Git to not assume my change to the first line is \"redundant\"?\n>\n\nMy guess is that you probably want a custom merge driver for your file\ntypes. That's where I would look initially.\n\nThanks,\nJake\n\n> Cheers,\n> Hilco\n>\n> [1] Note that this someone is (correctly) using the same, new version of 1.3.\n> [2] If my example is actually incorrect, then please just pretend\n> there are no conflicts.\n"},{"id":"310249","messageId":"CAE1pOi3eh7ao3NocV=PRFDby8y5ttjFR=-_VB0FoJv4MpjExaA@mail.gmail.com","threadId":"44974","inReplyTo":"CA+P7+xrupLuYAj7tn_1EaUiN6eaCmtgX-_d4mnByDq95cuqiWQ@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2017-01-25T22:51:48Z","receivedAt":"2017-01-25T22:52:15Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 25 January 2017 at 14:24, Jacob Keller wrote:\n> On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga\n> wrote:\n>> How can I force Git to not assume my change to the first line is \"redundant\"?\n>>\n>\n> My guess is that you probably want a custom merge driver for your file\n> types. That's where I would look initially.\n\nMmm, that sounds complex. The \"my-code.x\" is made up so I could keep\nmy example as simple as possible. In reality, it's Maven's POM files\n(pom.xml).\n\nSo there is no setting for any of this? There is no way to switch off\nauto merging for certain files?\n"},{"id":"310250","messageId":"CA+P7+xo9WBwHjAXeUTn4bh=F6hvw1gA-79h-GmwQoeRpeLj2jQ@mail.gmail.com","threadId":"44974","inReplyTo":"CAE1pOi3eh7ao3NocV=PRFDby8y5ttjFR=-_VB0FoJv4MpjExaA@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-25T22:54:08Z","receivedAt":"2017-01-25T22:54:34Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Jan 25, 2017 at 2:51 PM, Hilco Wijbenga\n wrote:\n> On 25 January 2017 at 14:24, Jacob Keller wrote:\n>> On Wed, Jan 25, 2017 at 2:16 PM, Hilco Wijbenga\n>> wrote:\n>>> How can I force Git to not assume my change to the first line is \"redundant\"?\n>>>\n>>\n>> My guess is that you probably want a custom merge driver for your file\n>> types. That's where I would look initially.\n>\n> Mmm, that sounds complex. The \"my-code.x\" is made up so I could keep\n> my example as simple as possible. In reality, it's Maven's POM files\n> (pom.xml).\n>\n> So there is no setting for any of this? There is no way to switch off\n> auto merging for certain files?\n\nNot really sure, but a quick google search revealed\nhttps://github.com/ralfth/pom-merge-driver\n\nMaybe that will help you?\n\nThanks,\nJake\n"},{"id":"310268","messageId":"xmqqh94m7leb.fsf@gitster.mtv.corp.google.com","threadId":"44974","inReplyTo":"CA+P7+xo9WBwHjAXeUTn4bh=F6hvw1gA-79h-GmwQoeRpeLj2jQ@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-25T23:46:52Z","receivedAt":"2017-01-25T23:47:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n>> Mmm, that sounds complex. The \"my-code.x\" is made up so I could keep\n>> my example as simple as possible. In reality, it's Maven's POM files\n>> (pom.xml).\n>>\n>> So there is no setting for any of this? There is no way to switch off\n>> auto merging for certain files?\n>\n> Not really sure, but a quick google search revealed\n> https://github.com/ralfth/pom-merge-driver\n>\n> Maybe that will help you?\n\nIts readme seems to indicate that it is either solving a different\nproblem, or solving the same problem with the opposite goal in mind,\nin that its goal seems to be to forcibly resolve what textually does\nnot resolve cleanly by choosing sides with an arbitrary policy, so\nthat humans do not have to get involved when they ordinarily would\nhave to.\n\nHilco's goal sounded to me the opposite---to force conflict even\nwhen the two histories did what textually does resolve cleanly and\nrequire humans to get involved even when they ordinarily wouldn't\nhave to.\n"},{"id":"310271","messageId":"CAE1pOi0CgfxQTygg_i3dc_-_Lb8qgOOk_0hg+goJvm7PyLZseg@mail.gmail.com","threadId":"44974","inReplyTo":"xmqqh94m7leb.fsf@gitster.mtv.corp.google.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2017-01-25T23:57:23Z","receivedAt":"2017-01-25T23:57:50Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 25 January 2017 at 15:46, Junio C Hamano wrote:\n> Jacob Keller writes:\n>\n>>> Mmm, that sounds complex. The \"my-code.x\" is made up so I could keep\n>>> my example as simple as possible. In reality, it's Maven's POM files\n>>> (pom.xml).\n>>>\n>>> So there is no setting for any of this? There is no way to switch off\n>>> auto merging for certain files?\n>>\n>> Not really sure, but a quick google search revealed\n>> https://github.com/ralfth/pom-merge-driver\n>>\n>> Maybe that will help you?\n>\n> Its readme seems to indicate that it is either solving a different\n> problem, or solving the same problem with the opposite goal in mind,\n> in that its goal seems to be to forcibly resolve what textually does\n> not resolve cleanly by choosing sides with an arbitrary policy, so\n> that humans do not have to get involved when they ordinarily would\n> have to.\n>\n> Hilco's goal sounded to me the opposite---to force conflict even\n> when the two histories did what textually does resolve cleanly and\n> require humans to get involved even when they ordinarily wouldn't\n> have to.\n\nYes, unfortunately, you are correct. This seems to do the exact\nopposite of what I want.\n\nBefore I start learning about custom merge drivers, is what I want\neven possible? If yes, would you happen to know some good examples of\n(custom) merge drivers? (Python, Ruby, Java are all okay.)\n"},{"id":"310275","messageId":"CA+P7+xocc==-8ad-OVTahMDABA0-spDPEw05JTHopfO7Ovj2RQ@mail.gmail.com","threadId":"44974","inReplyTo":"CAE1pOi0CgfxQTygg_i3dc_-_Lb8qgOOk_0hg+goJvm7PyLZseg@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-26T00:40:38Z","receivedAt":"2017-01-26T00:41:55Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Jan 25, 2017 at 3:57 PM, Hilco Wijbenga\n wrote:\n> On 25 January 2017 at 15:46, Junio C Hamano wrote:\n>> Jacob Keller writes:\n>>\n>>>> Mmm, that sounds complex. The \"my-code.x\" is made up so I could keep\n>>>> my example as simple as possible. In reality, it's Maven's POM files\n>>>> (pom.xml).\n>>>>\n>>>> So there is no setting for any of this? There is no way to switch off\n>>>> auto merging for certain files?\n>>>\n>>> Not really sure, but a quick google search revealed\n>>> https://github.com/ralfth/pom-merge-driver\n>>>\n>>> Maybe that will help you?\n>>\n>> Its readme seems to indicate that it is either solving a different\n>> problem, or solving the same problem with the opposite goal in mind,\n>> in that its goal seems to be to forcibly resolve what textually does\n>> not resolve cleanly by choosing sides with an arbitrary policy, so\n>> that humans do not have to get involved when they ordinarily would\n>> have to.\n>>\n>> Hilco's goal sounded to me the opposite---to force conflict even\n>> when the two histories did what textually does resolve cleanly and\n>> require humans to get involved even when they ordinarily wouldn't\n>> have to.\n>\n> Yes, unfortunately, you are correct. This seems to do the exact\n> opposite of what I want.\n>\n> Before I start learning about custom merge drivers, is what I want\n> even possible? If yes, would you happen to know some good examples of\n> (custom) merge drivers? (Python, Ruby, Java are all okay.)\n\nSetting the merge driver to \"unset\" will do what you want, but it\nwould leave the current branch as the tentative answer and doesn't\nactually make it easy to resolve properly. That would only require\nputting \"pom.xml merge=unset\" in the .gitattributes file.\n\nThat might be what you want, but it doesn't actually try to update the\nfile during the merge so you'd have to hand-fix it yourself.\n\nThanks,\nJake\n"},{"id":"310281","messageId":"xmqqd1fa7dqf.fsf@gitster.mtv.corp.google.com","threadId":"44974","inReplyTo":"CA+P7+xocc==-8ad-OVTahMDABA0-spDPEw05JTHopfO7Ovj2RQ@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-26T02:32:24Z","receivedAt":"2017-01-26T02:46:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n> Setting the merge driver to \"unset\" will do what you want, but it\n> would leave the current branch as the tentative answer and doesn't\n> actually make it easy to resolve properly. That would only require\n> putting \"pom.xml merge=unset\" in the .gitattributes file.\n\nWhere did you get that \"unset\" from? If that is this paragraph in\nDocumentation/gitattributes.txt:\n\n Unset::\n\n Take the version from the current branch as the\n tentative merge result, and declare that the merge has\n conflicts. This is suitable for binary files that do\n not have a well-defined merge semantics.\n\nyou'd need to read the beginning of the file to learn how to declare\nthat an attribute is Unset for the path. merge=unset is setting it\nto a string value, i.e. you are doing\n\n String::\n\n 3-way merge is performed using the specified custom\n merge driver. The built-in 3-way merge driver can be\n explicitly specified by asking for \"text\" driver; the\n built-in \"take the current branch\" driver can be\n requested with \"binary\".\n\ninstead, specifying a custom merge driver \"unset\", which would\nrequire something like\n\n [merge \"unset\"]\n name = feel-free merge driver\n driver = filfre %O %A %B %L %P\n recursive = binary\n\nin your configuration file.\n\n> That might be what you want, but it doesn't actually try to update the\n> file during the merge so you'd have to hand-fix it yourself.\n\nI think you should be able to do something like\n\n\t$ cat >$HOME/bin/fail-3way <<\\EOF\n\t#!/bin/sh\n\tgit merge-file \"$@\"\n\texit 1\n\tEOF\n\t$ chmod +x $HOME/bin/fail-3way\n\t$ cat >>$HOME/.gitconfig <<\\EOF\n\t[merge \"fail\"]\n\t\tname = always fail 3-way merge\n\t\tdriver = $HOME/bin/fail-3way %A %O %B\n\t\trecursive = text\n\tEOF\n\t$ echo pom.xml merge=fail >>.gitattributes\n\nto define a custom merge driver whose name is \"fail\", that runs the\nfail-3way program, which runs the bog standard 3-way merge we use\n(so that it will do the best-effort textual merge) but always return\nwith a non-zero status to signal that the result is conflicting and\nneeds manual resolution.\n\n\n"},{"id":"310293","messageId":"CA+P7+xqnaxWY+3Ve77ijFx4g-xLUh57c2+fadyHj5_iEuKtdUg@mail.gmail.com","threadId":"44974","inReplyTo":"xmqqd1fa7dqf.fsf@gitster.mtv.corp.google.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-01-26T05:05:02Z","receivedAt":"2017-01-26T05:05:37Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Jan 25, 2017 at 6:32 PM, Junio C Hamano wrote:\n> Where did you get that \"unset\" from? If that is this paragraph in\n> Documentation/gitattributes.txt:\n>\n\nOk so that whole section of documentation is very confusing to me.\nMaybe it could be improved for more readability. I'll see if I can't\nhelp clear up some of my confusion.\n\nThanks,\nJake\n"},{"id":"310352","messageId":"CAE1pOi0foJpZXSpHrbWqvOuG1+VoNKTCMjuLK5TCVcJuGMSOoQ@mail.gmail.com","threadId":"44974","inReplyTo":"xmqqd1fa7dqf.fsf@gitster.mtv.corp.google.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2017-01-26T19:19:51Z","receivedAt":"2017-01-26T19:20:18Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 25 January 2017 at 18:32, Junio C Hamano wrote:\n> I think you should be able to do something like\n>\n> $ cat >$HOME/bin/fail-3way <<\\EOF\n> #!/bin/sh\n> git merge-file \"$@\"\n> exit 1\n> EOF\n> $ chmod +x $HOME/bin/fail-3way\n> $ cat >>$HOME/.gitconfig <<\\EOF\n> [merge \"fail\"]\n> name = always fail 3-way merge\n> driver = $HOME/bin/fail-3way %A %O %B\n> recursive = text\n> EOF\n> $ echo pom.xml merge=fail >>.gitattributes\n>\n> to define a custom merge driver whose name is \"fail\", that runs the\n> fail-3way program, which runs the bog standard 3-way merge we use\n> (so that it will do the best-effort textual merge) but always return\n> with a non-zero status to signal that the result is conflicting and\n> needs manual resolution.\n\nThank you, that's an improvement. :-) Unfortunately, it still\ncompletes the merge. Is there any way to simply get the\n>>>>>>>>/<<<<<<<< markers?\n"},{"id":"310357","messageId":"xmqqy3xx35pn.fsf@gitster.mtv.corp.google.com","threadId":"44974","inReplyTo":"CAE1pOi0foJpZXSpHrbWqvOuG1+VoNKTCMjuLK5TCVcJuGMSOoQ@mail.gmail.com","subject":"Re: Force Confirmation for Dropping Changed Lines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-26T20:51:32Z","receivedAt":"2017-01-26T20:57:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n> On 25 January 2017 at 18:32, Junio C Hamano wrote:\n>> I think you should be able to do something like\n>>\n>> $ cat >$HOME/bin/fail-3way <<\\EOF\n>> #!/bin/sh\n>> git merge-file \"$@\"\n>> exit 1\n>> EOF\n>> $ chmod +x $HOME/bin/fail-3way\n>> $ cat >>$HOME/.gitconfig <<\\EOF\n>> [merge \"fail\"]\n>> name = always fail 3-way merge\n>> driver = $HOME/bin/fail-3way %A %O %B\n>> recursive = text\n>> EOF\n>> $ echo pom.xml merge=fail >>.gitattributes\n>>\n>> to define a custom merge driver whose name is \"fail\", that runs the\n>> fail-3way program, which runs the bog standard 3-way merge we use\n>> (so that it will do the best-effort textual merge) but always return\n>> with a non-zero status to signal that the result is conflicting and\n>> needs manual resolution.\n>\n> Thank you, that's an improvement. :-) Unfortunately, it still\n> completes the merge. Is there any way to simply get the\n>>>>>>>>>/<<<<<<<< markers?\n\nYou can, but you need to write one yourself without relying on \"git\nmerge-file\", because the whole point of the 3way merge we implement\n(including in that program) is \"do not bother the user when both\nsides made the same change.\"\n\n"}]}