{"thread":{"id":"16520","subject":"more merge strategies : feature request","startedAt":"2008-11-29T16:48:45Z","lastAt":"2008-12-04T10:11:07Z","messageCount":13,"participants":["Caleb Cushing","Andreas Ericsson","Leo Razoumov","Jeff King","Nanako Shiraishi","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96728","messageId":"81bfc67a0811290848m6cb219c0y71a7266001096f2d@mail.gmail.com","threadId":"16520","inReplyTo":null,"subject":"more merge strategies : feature request","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-11-29T16:48:45Z","receivedAt":"2008-11-29T16:48:45Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"conflict: this strategy would always resolve in a merge conflict\nallowing you to use git mergetool to piece the files back together.\n\nno-overwrite: if a change from the branch being merged in would\noverwrite something in the current branch don't merge it. (I think it\nneeds a better name)\n\n\n-- \nCaleb Cushing\n"},{"id":"96816","messageId":"4933AC03.6050300@op5.se","threadId":"16520","inReplyTo":"81bfc67a0811290848m6cb219c0y71a7266001096f2d@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-12-01T09:18:59Z","receivedAt":"2008-12-01T09:18:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Caleb Cushing wrote:\n> conflict: this strategy would always resolve in a merge conflict\n> allowing you to use git mergetool to piece the files back together.\n> \n> no-overwrite: if a change from the branch being merged in would\n> overwrite something in the current branch don't merge it. (I think it\n> needs a better name)\n> \n\nIf you could come up with use-cases where each would be useful, I\nthink you'd have a much easier time to gain acceptance for your\nsuggestions. Right now, you're saying \"I want a red button\" but\nyou're not explaining what it's for.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"96917","messageId":"81bfc67a0812011838m68100020v727da1c06f0bcee4@mail.gmail.com","threadId":"16520","inReplyTo":"4933AC03.6050300@op5.se","subject":"Re: more merge strategies : feature request","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-12-02T02:38:07Z","receivedAt":"2008-12-02T02:38:07Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"> If you could come up with use-cases where each would be useful, I\n> think you'd have a much easier time to gain acceptance for your\n> suggestions. Right now, you're saying \"I want a red button\" but\n> you're not explaining what it's for.\n\nconflict: when auto-merging isn't merging the way you want it too, but\nyou still want to see the diffs and handle them by hand. no commit\nwon't do this, it just doesn't commit. I've had 2 situations now where\ngit's fast-forward has overwritten changes in a branch I didn't want\nit to, it would have been better if I could handle them by hand\nwithout having to have 1 terminal open to the diff and the other open\nto the editor to fix it. and yes git was right by it's perspective,\nbut the code it created was wrong by what I wanted and needed. I'm not\nreally sure what more of a use case is needed for this.\n\nno-overwrite: it's basically my way of saying that even though git\nthinks it's changes are newer and better than the ones in my branch I\nknow they aren't. I only want the new stuff from the other branch. In\nthe second situation mentioned above I have 2 branches that I like to\nmerge back and forth, each needing a specific set of changes to\ncertain files however most changes are shared. when I merge them I\noften have to change those specific changes back, if it didn't\novewrite them I wouldn't have a problem.\n\nfor example I'm tracking my dot files with git, in my main user\naccount I set umask 077 however in my web development account I need\numask 027 so apache can read the files I create. when I create a\nchange in webdev and need to merge it back into master it overwrites\nthe 077 umask which I then change back. when I create a change in\nmaster that I want in webdev it then changes webdev's umask. very\nannoying.\n\nthe other problem I had was where I'd overwritten a file in another\nbranch just for the point of merging it into the master branch so I\ncould see the differences, and handle them properly (as I see it)\nunfortunately git felt that this file was newer and simply overwrote\nthe changes in master. this was incorrect they were simply different\nversions of the same type of file, like comparing an httpd.conf from a\ngentoo and another from a fedora system. I was merely trying to figure\nthe best of both files to get the results I wanted.\n\ntechnically the conflict strategy I propose would be adequate for both\nbut the no-overwrite seems like a good idea as well.\n\n\n\n\n\n\n-- \nCaleb Cushing\n"},{"id":"96922","messageId":"ee2a733e0812011849l1b319c96u9abbb4e8dd4f53ce@mail.gmail.com","threadId":"16520","inReplyTo":"4933AC03.6050300@op5.se","subject":"Re: more merge strategies : feature request","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-12-02T02:49:08Z","receivedAt":"2008-12-02T02:49:08Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 12/1/08, Andreas Ericsson wrote:\n> Caleb Cushing wrote:\n>\n> > conflict: this strategy would always resolve in a merge conflict\n> > allowing you to use git mergetool to piece the files back together.\n> >\n> > no-overwrite: if a change from the branch being merged in would\n> > overwrite something in the current branch don't merge it. (I think it\n> > needs a better name)\n> >\n\nI guess that \"no-overwrite\" can be achieved by\n\ngit merge -s ours --no-commit\n\n--Leo--\n"},{"id":"96927","messageId":"20081202033013.GD6804@coredump.intra.peff.net","threadId":"16520","inReplyTo":"81bfc67a0812011838m68100020v727da1c06f0bcee4@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-02T03:30:14Z","receivedAt":"2008-12-02T03:30:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 01, 2008 at 09:38:07PM -0500, Caleb Cushing wrote:\n\n> conflict: when auto-merging isn't merging the way you want it too, but\n> you still want to see the diffs and handle them by hand. no commit\n> won't do this, it just doesn't commit. I've had 2 situations now where\n> git's fast-forward has overwritten changes in a branch I didn't want\n> it to, it would have been better if I could handle them by hand\n> without having to have 1 terminal open to the diff and the other open\n> to the editor to fix it. and yes git was right by it's perspective,\n> but the code it created was wrong by what I wanted and needed. I'm not\n> really sure what more of a use case is needed for this.\n\nIt's not clear to me exactly what you want. Let's say I have a file\n'foo' with changes from my merged branches in two different spots.\nFor example:\n\n merge base branch A branch B\n 1 2 1\n 2 3 2\n 3 4 3\n 4 5 4\n 5\n\nDid you want conflict markers in the resulting file? If so, what should\nthe conflict markers look like, since there isn't actually a conflict?\n\nAlternatively, you could have git leave the file in an unmerged state,\nand then access the base, ours, and theirs version from the index (or\neven use git mergetool). Then you would get your desired versions into\nthe merging tool of your choice.\n\nOf course, you could also just use a custom merge driver to accomplish\nthe same thing:\n\n git config merge.xxdiff.driver 'xxdiff %A %O %B'\n echo '* merge=xxdiff' >.gitattributes\n git merge your-branch\n\nand of course you can specify whatever subset of files you want to\nactually do this for instead of '*'.\n\n-Peff\n"},{"id":"96940","messageId":"81bfc67a0812020546o79906a20jcd04bd42d18dd803@mail.gmail.com","threadId":"16520","inReplyTo":"ee2a733e0812011849l1b319c96u9abbb4e8dd4f53ce@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-12-02T13:46:00Z","receivedAt":"2008-12-02T13:46:00Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"> I guess that \"no-overwrite\" can be achieved by\n>\n> git merge -s ours --no-commit\n\nno it doesn't. which is why I called it a bad name. no-overwrite would\nstill add new lines to the file not in ours (and no-commit isn't\nneeded in that case) it just wouldn't overwrite conflicting lines, my\nunderstanding of ours is that it will keep the files as is.\nCaleb Cushing\n"},{"id":"96943","messageId":"81bfc67a0812020628l53c209a6yca5a619d211b6bfc@mail.gmail.com","threadId":"16520","inReplyTo":"20081202033013.GD6804@coredump.intra.peff.net","subject":"Re: more merge strategies : feature request","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-12-02T14:28:41Z","receivedAt":"2008-12-02T14:28:41Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":">\n> It's not clear to me exactly what you want. Let's say I have a file\n> ....\n\nI'm afraid I don't fully understand your example\n\n\nlets say git merge foo bar\nfoo bar\n1 1\n2 8\n3 3\n4 4\n5 5\n6\n7\n\nlines 6 and 7 are new in foo line 2 has a conflict because the other\nhead has an 8, history wise because of an early merge the other\ndirection and fix, there was the 8 in foo and it was changed to a 2,\nwhen I merge back it will overwrite the 8 with a 2. however I need\nthe 8 to be the 8 and the 2 to be the 2. but I want the 6 and 7 in\nboth.\n\nconflict would create a conflict\n\nsuch as\n\nfoo\n1\n<<<<<< bar\n8\n======\n2\n>>>>>> foo\n3\n4\n5\n6\n7\n\nno overwrite would result in file1 looking like this\n\n1\n8\n3\n4\n5\n6\n7\n\n> Did you want conflict markers in the resulting file? If so, what should\n> the conflict markers look like, since there isn't actually a conflict?\n\nif the the remote and local branches are not identical there's a\ndifference which should be able to result in a conflict. for all\npurposes I'm not sure git couldn't just ignore the history of the\nfiles and do a straight head to head merge. the steps you suggest\nmake it more complicated than it needs to be an if done post merge or\nwithout merge will probably be need to be done again in a future merge\nif merging back and forth\n\n\n-- \nCaleb Cushing\n"},{"id":"96951","messageId":"20081202153036.GC15134@coredump.intra.peff.net","threadId":"16520","inReplyTo":"81bfc67a0812020628l53c209a6yca5a619d211b6bfc@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-02T15:30:36Z","receivedAt":"2008-12-02T15:30:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2008 at 09:28:41AM -0500, Caleb Cushing wrote:\n\n> I'm afraid I don't fully understand your example\n> \n> \n> lets say git merge foo bar\n> foo bar\n> 1 1\n> 2 8\n> 3 3\n> 4 4\n> 5 5\n> 6\n> 7\n\nI notice that you don't have a \"merge base\" here, which is an important\npart of determining conflicts. So if you are proposing to not look at\nthe history at all, and just show all differences, then that is\ndifferent from what I thought you meant.\n\n> lines 6 and 7 are new in foo line 2 has a conflict because the other\n> head has an 8, history wise because of an early merge the other\n> direction and fix, there was the 8 in foo and it was changed to a 2,\n> when I merge back it will overwrite the 8 with a 2. however I need\n> the 8 to be the 8 and the 2 to be the 2. but I want the 6 and 7 in\n> both.\n>\n> conflict would create a conflict\n> \n> such as\n> \n> foo\n> 1\n> <<<<<< bar\n> 8\n> ======\n> 2\n> >>>>>> foo\n> 3\n> 4\n> 5\n> 6\n> 7\n\nOK, so assume we throw away history and just look at the diff between\nthe two branches. How do we know that a conflict should be created for\nthe 2 vs 8, but not for the added \"6 7\" at the end? I think you have to\ncreate a conflict marker for both and fix them up manually. Like:\n\n 1\n <<<<<<< foo\n 2\n =======\n 8\n >>>>>>> bar\n 3\n 4\n 5\n <<<<<<< foo\n 6\n 7\n =======\n >>>>>>> bar\n\nThe script below munges a diff into conflict markers (and created the\noutput you see above). Note that it is very hacky and not very tested.\nAnd note that at this point this really has nothing to do with _git_\nspecifically, since we aren't even using history. This just generates\nconflict markers from two files. There may be a more mature tool that\ncan accomplish the same thing (personally, I would use something like\nxxdiff to do an interactive merge in your case).\n\nYou can try it with:\n\n git config merge.conflict.driver 'perl /path/to/conflict.pl %A %B'\n echo '* merge=conflict' >.gitattributes\n\n-->8 conflict.pl 8<--\n#!/usr/bin/perl\n\nuse strict;\nuse warnings qw(all FATAL);\n\nmy $fn1 = shift;\nmy $fn2 = shift;\n\nopen(my $diff, '-|', qw(diff -U 999999), $fn1, $fn2)\n or die \"unable to run diff: $!\";\nopen(my $tmp, '>', \"$fn1.tmp\")\n or die \"unable to open temporary file: $!\";\nselect $tmp;\n\nwhile(<$diff>) {\n last if /^@/;\n}\n\nsub start { print \"<<<<<<< $fn1\\n\" }\nsub divider { print \"=======\\n\" }\nsub end { print \">>>>>>> $fn2\\n\" }\nmy $conflict = 0;\nwhile(<$diff>) {\n if (/^ (.*)/) {\n if ($conflict == 0) { }\n elsif ($conflict == 1) { divider; end }\n elsif ($conflict == 2) { end }\n print $1, \"\\n\";\n $conflict = 0;\n }\n elsif(/^-(.*)/) {\n if ($conflict == 0) { start }\n elsif ($conflict == 1) { }\n elsif ($conflict == 2) { end; start }\n print $1, \"\\n\";\n $conflict = 1;\n }\n elsif(/^\\+(.*)/) {\n if ($conflict == 0) { start; divider }\n elsif ($conflict == 1) { divider }\n elsif ($conflict == 2) { }\n print $1, \"\\n\";\n $conflict = 2;\n }\n}\n\nif ($conflict == 0) { }\nelsif ($conflict == 1) { divider; end }\nelsif ($conflict == 2) { end }\n\nclose($tmp);\nrename \"$fn1.tmp\", $fn1;\nexit 1;\n"},{"id":"97002","messageId":"ee2a733e0812021707i82049eai866035aef3386264@mail.gmail.com","threadId":"16520","inReplyTo":"81bfc67a0812020546o79906a20jcd04bd42d18dd803@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Leo Razoumov","fromEmail":"slonik.az@gmail.com","sentAt":"2008-12-03T01:07:36Z","receivedAt":"2008-12-03T01:07:36Z","isPatch":false,"sender":{"key":"slonik.az@gmail.com","avatar":null},"body":"On 12/2/08, Caleb Cushing wrote:\n> > I guess that \"no-overwrite\" can be achieved by\n> >\n> > git merge -s ours --no-commit\n>\n>\n> no it doesn't. which is why I called it a bad name. no-overwrite would\n> still add new lines to the file not in ours (and no-commit isn't\n> needed in that case) it just wouldn't overwrite conflicting lines, my\n> understanding of ours is that it will keep the files as is.\n>\n> Caleb Cushing\n>\n\n>From your original email in this thread\n\n\"no-overwrite: if a change from the branch being merged in would\noverwrite something in the current branch don't merge it. (I think it\nneeds a better name)\"\n\nI got the impression that you would like to preserve \"ours\" branch\nwhenever other branch tries to overwrite something? Is it\n\"no-override-conflicting-lines\" that you are really after?\n\n--Leo--\n"},{"id":"97098","messageId":"20081204062717.6117@nanako3.lavabit.com","threadId":"16520","inReplyTo":"ee2a733e0812021707i82049eai866035aef3386264@mail.gmail.com","subject":"Re: more merge strategies : feature request","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-12-03T21:27:17Z","receivedAt":"2008-12-03T21:27:17Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting \"Leo Razoumov\" :\n\n> On 12/2/08, Caleb Cushing wrote:\n>> > I guess that \"no-overwrite\" can be achieved by\n>> >\n>> > git merge -s ours --no-commit\n>>\n>> no it doesn't. which is why I called it a bad name. no-overwrite would\n>> still add new lines to the file not in ours (and no-commit isn't\n>> needed in that case) it just wouldn't overwrite conflicting lines, my\n>> understanding of ours is that it will keep the files as is.\n\nIsn't what Caleb wants \"-X ours/theirs\" per-hunk option for merge strategy backends?\n\nIt was discussed several months ago on the list and was rejected. For details you can start here:\n\n http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021\n\nI still think the patch in the above link was reasonable, but the thread was distracted into discussing minor syntactical details of how the option gets passed to the backend, and the rest of the discussion to decide if it makes sense to add such a feature was unfortunately lost in the noise and never concluded.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"97108","messageId":"81bfc67a0812031459g4c30908ew46e4cf2bd6445f64@mail.gmail.com","threadId":"16520","inReplyTo":"20081204062717.6117@nanako3.lavabit.com","subject":"Re: more merge strategies : feature request","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-12-03T22:59:56Z","receivedAt":"2008-12-03T22:59:56Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"> Isn't what Caleb wants \"-X ours/theirs\" per-hunk option for merge strategy backends?\n\njust from this description it sounds like it. I can't say anything\nabout that patch, but to me having such a strategy only makes sense.\n\n-- \nCaleb Cushing\n"},{"id":"97127","messageId":"7vabbc7kk5.fsf@gitster.siamese.dyndns.org","threadId":"16520","inReplyTo":"20081204062717.6117@nanako3.lavabit.com","subject":"Re: more merge strategies : feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-04T02:15:06Z","receivedAt":"2008-12-04T02:15:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Isn't what Caleb wants \"-X ours/theirs\" per-hunk option for merge strategy backends?\n>\n> It was discussed several months ago on the list and was rejected. For details you can start here:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021\n>\n> I still think the patch in the above link was reasonable, but the thread\n> was distracted into discussing minor syntactical details of how the\n> option gets passed to the backend, and the rest of the discussion to\n> decide if it makes sense to add such a feature was unfortunately lost in\n> the noise and never concluded.\n\nI thought http://article.gmane.org/gmane.comp.version-control.git/89033 in\nthe thread (and your response to it which is 89175) pretty much concluded\nthe discussion. Is Caleb adding anything new to the discussion (iow, is\nthere a convincing new argument why having such a merge is a good idea and\nwhat the workflow looks like that benefits from it)?\n"},{"id":"97139","messageId":"20081204191107.6117@nanako3.lavabit.com","threadId":"16520","inReplyTo":"7vabbc7kk5.fsf@gitster.siamese.dyndns.org","subject":"Re: more merge strategies : feature request","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-12-04T10:11:07Z","receivedAt":"2008-12-04T10:11:07Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> I thought http://article.gmane.org/gmane.comp.version-control.git/89033 in\n> the thread (and your response to it which is 89175) pretty much concluded\n> the discussion. Is Caleb adding anything new to the discussion (iow, is\n> there a convincing new argument why having such a merge is a good idea and\n> what the workflow looks like that benefits from it)?\n\nI first thought so, but after reading this feature request thread again I do not think so anymore.\n\nSorry for the noise.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"}]}