{"thread":{"id":"14719","subject":"theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","startedAt":"2008-07-28T14:54:17Z","lastAt":"2008-07-29T12:42:13Z","messageCount":28,"participants":["Sverre Rabbelier","Miklos Vajna","Jeff King","Johannes Schindelin","Avery Pennarun","Junio C Hamano","Mike Ralphson"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"85296","messageId":"bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com","threadId":"14719","inReplyTo":null,"subject":"theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T14:54:17Z","receivedAt":"2008-07-28T14:54:17Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 15:12, Johannes Schindelin\n wrote:\n> Note that what was asked for, and what Junio implemented before deciding\n> that it would do more harm than good in git.git, is not the same as what\n> you provide.\n>\n> Your -theirs is a strict opposite of -ours, i.e. the tree after the\n> merge will be identical to the \"merged\" branch's tip's.\n\nI've been wanting to mail about this for a few days now, but didn't\nreally know how to bring it up, this seems a good opportunity.\n\nIt has happened a few times on #git already that someone asked for the\nmerge strategies described above (e.g., _not_ the insane ones) for\nwhat I deemed to be valid use cases. (The main reason was that they\nwanted to merge with a conflicting branch, discarding the current\nmaster, but still allowing people to 'git pull'.)\n\nI was wondering what to tell those people? Will there ever be such a\nversion of 'merge theirs' (that is the strict opposite of 'ours')? Or\nshould they do:\n\n$git checkout otherbranch\n$git merge -s ours master\n$git checkout master\n$git merge otherbranch\n\nThus resulting in a 'wrong way around' merge as part of master? It\nwould say \"Merge branch 'master' into otherbranch\", while what\nhappened was \"Merge branch 'otherbranch' into master\".\n\nSo, in short: what does the list think about adding\n\"git-merge-theirs\", that does (although possibly less 'hackish'):\n\ncat > git-merge-theirs << EOF\n#!/bin/sh\neval git read-tree --reset -u \\\\\\$\\$#\nEOF\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85314","messageId":"20080728181424.GM32057@genesis.frugalware.org","threadId":"14719","inReplyTo":"bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-07-28T18:14:24Z","receivedAt":"2008-07-28T18:14:24Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:\n> So, in short: what does the list think about adding\n> \"git-merge-theirs\", that does (although possibly less 'hackish'):\n> \n> cat > git-merge-theirs << EOF\n> #!/bin/sh\n> eval git read-tree --reset -u \\\\\\$\\$#\n> EOF\n\nIsn't this the stupid one?\n\nIt's perfect for my testing needs, but this is not something that people\nshould ever use on a real repo.\n"},{"id":"85318","messageId":"20080728185604.GA26322@sigill.intra.peff.net","threadId":"14719","inReplyTo":"bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-28T18:56:04Z","receivedAt":"2008-07-28T18:56:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:\n\n> Thus resulting in a 'wrong way around' merge as part of master? It\n> would say \"Merge branch 'master' into otherbranch\", while what\n> happened was \"Merge branch 'otherbranch' into master\".\n> \n> So, in short: what does the list think about adding\n> \"git-merge-theirs\", that does (although possibly less 'hackish'):\n> \n> cat > git-merge-theirs << EOF\n> #!/bin/sh\n> eval git read-tree --reset -u \\\\\\$\\$#\n> EOF\n\nI ran into this exact situation while showing somebody how awesome git\nwas, and it was a little embarrasing to say \"oops, now we have to do\nthis backwards.\"\n\nSo I think it would be nice for completeness, although I admit that my\nsituation was rare (but no rarer, perhaps, than \"-s ours\").\n\n-Peff\n\nPS You may find your shell snippet a bit more readable by quoting 'EOF'.\n"},{"id":"85320","messageId":"alpine.DEB.1.00.0807282008470.8986@racer","threadId":"14719","inReplyTo":"20080728185604.GA26322@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-28T19:09:55Z","receivedAt":"2008-07-28T19:09:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Jul 2008, Jeff King wrote:\n\n> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:\n> \n> > Thus resulting in a 'wrong way around' merge as part of master? It\n> > would say \"Merge branch 'master' into otherbranch\", while what\n> > happened was \"Merge branch 'otherbranch' into master\".\n> > \n> > So, in short: what does the list think about adding\n> > \"git-merge-theirs\", that does (although possibly less 'hackish'):\n> > \n> > cat > git-merge-theirs << EOF\n> > #!/bin/sh\n> > eval git read-tree --reset -u \\\\\\$\\$#\n> > EOF\n> \n> I ran into this exact situation while showing somebody how awesome git\n> was, and it was a little embarrasing to say \"oops, now we have to do\n> this backwards.\"\n\nWell, I have to say that the workflow is a bit backwards if the person who \n_publishes_ the thing is the one saying \"Ooops, my version no goodie, \nother version please, but so that pull still works\".\n\nI would have expected the one who has the good version to make the choice.\n\nCiao,\nDscho\n"},{"id":"85325","messageId":"20080728192651.GA26677@sigill.intra.peff.net","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807282008470.8986@racer","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-28T19:26:51Z","receivedAt":"2008-07-28T19:26:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:\n\n> Well, I have to say that the workflow is a bit backwards if the person who \n> _publishes_ the thing is the one saying \"Ooops, my version no goodie, \n> other version please, but so that pull still works\".\n> \n> I would have expected the one who has the good version to make the choice.\n\nMy situation was two long-running branches, \"stable\" and \"devel\",\nboth of which were worked on by many developers. One person was in\ncharge of integration and branch management. They wanted \"stable\" to\nget the contents of \"devel\" (which were now ready for release), ignoring\nany small fixes that had been done on \"stable\" (since they had all been\nmoved over to \"devel\" previously, but in subtly different ways that\nwould create conflicts). And \"git reset\" was not an option, because they\nwanted to keep the history of \"stable\" in case those fixes needed to be\nlooked at later.\n\nSo the logical sequence was:\n\n git checkout production\n git merge -s theirs master\n\n-Peff\n"},{"id":"85326","messageId":"bd6139dc0807281248m51997c58q5a7aaf3ac51ee7a@mail.gmail.com","threadId":"14719","inReplyTo":"20080728181424.GM32057@genesis.frugalware.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T19:48:08Z","receivedAt":"2008-07-28T19:48:08Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 20:14, Miklos Vajna wrote:\n> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:\n>> So, in short: what does the list think about adding\n>> \"git-merge-theirs\", that does (although possibly less 'hackish'):\n>>\n>> cat > git-merge-theirs << EOF\n>> #!/bin/sh\n>> eval git read-tree --reset -u \\\\\\$\\$#\n>> EOF\n>\n> Isn't this the stupid one?\n\nNo, the stupid one did \"take all non-conflicting hunks from our side,\nand any for conflicting hunks, take theirs\", which was rather silly I\nmust say, although I have heard one use-cases where it makes sense (no\nI don't think we should have a git-merge-theirs-on-conflict).\n\n> It's perfect for my testing needs, but this is not something that people\n> should ever use on a real repo.\n\nWhat about the use-case I described in my first mail?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85327","messageId":"bd6139dc0807281252y650b9347md1d4ac788151d19f@mail.gmail.com","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807282008470.8986@racer","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T19:52:38Z","receivedAt":"2008-07-28T19:52:38Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 21:09, Johannes Schindelin\n wrote:\n> Well, I have to say that the workflow is a bit backwards if the person who\n> _publishes_ the thing is the one saying \"Ooops, my version no goodie,\n> other version please, but so that pull still works\".\n\nWhy so? In this case the other branch was also owned by the publishing\nperson. I don't quite follow how this is any stranger than ours?\n(Which is stranger to me, why would you want to merge in a branch if\nyou're not going to do anything with it anyway? I'm sure there are\nvalid workflows for it, which is why we have it, just saying that I\nthink 'theirs' makes more sense to me than 'ours')\n\n> I would have expected the one who has the good version to make the choice.\n\nWhy have the person with the good version merge with... a bad version?\nIsn't it usually \"I will merge with you, because I know your branch\nmakes things go twice as fast\" (paraphrasing Linus from his git talk\nat google).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85329","messageId":"32541b130807281300yb93884anf28f3ddb2cc507d@mail.gmail.com","threadId":"14719","inReplyTo":"20080728192651.GA26677@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-28T20:00:42Z","receivedAt":"2008-07-28T20:00:42Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/28/08, Jeff King wrote:\n> My situation was two long-running branches, \"stable\" and \"devel\",\n> both of which were worked on by many developers. One person was in\n> charge of integration and branch management. They wanted \"stable\" to\n> get the contents of \"devel\" (which were now ready for release), ignoring\n> any small fixes that had been done on \"stable\" (since they had all been\n> moved over to \"devel\" previously, but in subtly different ways that\n> would create conflicts). And \"git reset\" was not an option, because they\n> wanted to keep the history of \"stable\" in case those fixes needed to be\n> looked at later.\n>\n> So the logical sequence was:\n>\n> git checkout production\n> git merge -s theirs master\n\nI have to say, this somehow feels wrong to me. What you're saying is\nessentially that \"stable has already been merged into devel\" followed\nby \"and now we want to catch stable up to devel.\"\n\nIt really is two separate thoughts, and merging devel directly into\nstable - literally by *undoing* all the changes from stable - doesn't\nsound like it should be considered a safe operation.\n\nPersonally, I've started enjoying the \"--no-ff\" option to git-merge.\nThat way I can do\n\n git checkout master\n git merge production\n git checkout production\n git merge --no-ff master\n\nThe latter merge isn't really a \"merge\" since it could have been just\nfast forwarded. But it avoids the aesthetic problems of commits like\n\"merge production into master\" showing up in the master branch. It\nalso means that \"git reset --hard HEAD^\" works whether or not a\nfastforward would have been theoretically possible.\n\nOf course, this whole discussion is really just about how to make your\nlog look cleaner, and we could debate forever about that. It may make\nsense to simply provide \"theirs\" as an exact mirror of \"ours\" if only\nin the name of symmetry.\n\nHave fun,\n\nAvery\n"},{"id":"85330","messageId":"7vproxrcvu.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807282008470.8986@racer","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-28T20:07:33Z","receivedAt":"2008-07-28T20:07:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Well, I have to say that the workflow is a bit backwards if the person who \n> _publishes_ the thing is the one saying \"Ooops, my version no goodie, \n> other version please, but so that pull still works\".\n>\n> I would have expected the one who has the good version to make the choice.\n\nThat reminds me of:\n\n http://thread.gmane.org/gmane.comp.version-control.git/89178\n\nto one of whose messages I sent a response today.\n"},{"id":"85331","messageId":"bd6139dc0807281310j16b4ef5alf9738ec0f3270ba0@mail.gmail.com","threadId":"14719","inReplyTo":"7vproxrcvu.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T20:10:50Z","receivedAt":"2008-07-28T20:10:50Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 22:07, Junio C Hamano wrote:\n> That reminds me of:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/89178\n>\n> to one of whose messages I sent a response today.\n\nMhhh, but the proposed strategy there was in response to the 'insane'\ngit-merge-theirs version, not to the 'exact opposite of\ngit-merge-ours' that I refer to now, yes? Do you have any particular\nfeelings wrt to that?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85332","messageId":"7vljzlrca9.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"bd6139dc0807281310j16b4ef5alf9738ec0f3270ba0@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-28T20:20:30Z","receivedAt":"2008-07-28T20:20:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> On Mon, Jul 28, 2008 at 22:07, Junio C Hamano wrote:\n>> That reminds me of:\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/89178\n>>\n>> to one of whose messages I sent a response today.\n>\n> Mhhh, but the proposed strategy there was in response to the 'insane'\n> git-merge-theirs version, not to the 'exact opposite of\n> git-merge-ours' that I refer to now, yes?\n\nNo.\n"},{"id":"85334","messageId":"bd6139dc0807281324k38198fffwd3b586394b354ed2@mail.gmail.com","threadId":"14719","inReplyTo":"7vljzlrca9.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T20:24:10Z","receivedAt":"2008-07-28T20:24:10Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 22:20, Junio C Hamano wrote:\n> \"Sverre Rabbelier\" writes:\n>> Mhhh, but the proposed strategy there was in response to the 'insane'\n>> git-merge-theirs version, not to the 'exact opposite of\n>> git-merge-ours' that I refer to now, yes?\n>\n> No.\n\nNanako Shiraishi's patch was not in response to the \"git-merge-theirs\"\nthread, or I am missing something here....?\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85340","messageId":"7vvdyppv4c.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"bd6139dc0807281324k38198fffwd3b586394b354ed2@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-28T21:16:35Z","receivedAt":"2008-07-28T21:16:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano wrote:\n>> \"Sverre Rabbelier\" writes:\n>>> Mhhh, but the proposed strategy there was in response to the 'insane'\n>>> git-merge-theirs version, not to the 'exact opposite of\n>>> git-merge-ours' that I refer to now, yes?\n>>\n>> No.\n>\n> Nanako Shiraishi's patch was not in response to the \"git-merge-theirs\"\n> thread, or I am missing something here....?\n\nThe quoted sentence by me in that message was after I explained why \"per\nhunk theirs\" aka \"-Xtheirs\" was not such a great idea I further went on to\nsay \"by the way, '-s theirs' is even worse and here is why\".\n"},{"id":"85341","messageId":"7vr69dpu9i.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"7vvdyppv4c.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-28T21:35:05Z","receivedAt":"2008-07-28T21:35:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"Sverre Rabbelier\" writes:\n>\n>> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano wrote:\n>>> \"Sverre Rabbelier\" writes:\n>>>> Mhhh, but the proposed strategy there was in response to the 'insane'\n>>>> git-merge-theirs version, not to the 'exact opposite of\n>>>> git-merge-ours' that I refer to now, yes?\n>>>\n>>> No.\n>>\n>> Nanako Shiraishi's patch was not in response to the \"git-merge-theirs\"\n>> thread, or I am missing something here....?\n>\n> The quoted sentence by me in that message was after I explained why \"per\n> hunk theirs\" aka \"-Xtheirs\" was not such a great idea I further went on to\n> say \"by the way, '-s theirs' is even worse and here is why\".\n\nHeh, I ended up doing the \"digging\" myself. The quote came from this:\n\n http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024\n\nand \"tried not to sound too negative\" there refers to:\n\n http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021\n\nwhich _was_ about the \"-Xtheirs\", not \"-s theirs\".\n"},{"id":"85342","messageId":"bd6139dc0807281439i7f40a914s3cda16a2bdbf6857@mail.gmail.com","threadId":"14719","inReplyTo":"7vr69dpu9i.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-28T21:39:31Z","receivedAt":"2008-07-28T21:39:31Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Jul 28, 2008 at 23:35, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>> The quoted sentence by me in that message was after I explained why \"per\n>> hunk theirs\" aka \"-Xtheirs\" was not such a great idea I further went on to\n>> say \"by the way, '-s theirs' is even worse and here is why\".\n\nAaah, ok, now I see where my confusion came from. Thank you for\nclarifying that. Then remains the question, what to tell those that\nwant '-s theirs' not to keep track of their changes, but to keep a\nfast-forwardable master?\n\n> Heh, I ended up doing the \"digging\" myself. The quote came from this:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024\n>\n> and \"tried not to sound too negative\" there refers to:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021\n>\n> which _was_ about the \"-Xtheirs\", not \"-s theirs\".\n\nUnderstood, it makes sense now.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85355","messageId":"alpine.DEB.1.00.0807290123300.2725@eeepc-johanness","threadId":"14719","inReplyTo":"20080728192651.GA26677@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-28T23:27:44Z","receivedAt":"2008-07-28T23:27:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Jul 2008, Jeff King wrote:\n\n> On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:\n> \n> > Well, I have to say that the workflow is a bit backwards if the person \n> > who _publishes_ the thing is the one saying \"Ooops, my version no \n> > goodie, other version please, but so that pull still works\".\n> > \n> > I would have expected the one who has the good version to make the \n> > choice.\n> \n> My situation was two long-running branches, \"stable\" and \"devel\", both \n> of which were worked on by many developers. One person was in charge of \n> integration and branch management. They wanted \"stable\" to get the \n> contents of \"devel\" (which were now ready for release), ignoring any \n> small fixes that had been done on \"stable\" (since they had all been \n> moved over to \"devel\" previously, but in subtly different ways that \n> would create conflicts). And \"git reset\" was not an option, because they \n> wanted to keep the history of \"stable\" in case those fixes needed to be \n> looked at later.\n> \n> So the logical sequence was:\n> \n> git checkout production\n> git merge -s theirs master\n\nTo me, this suggests that they were too married to 'production' being the \n\"dominant\" branch.\n\nThing is: they had two branches. They should be merged, but one should \nprevail: 'master'.\n\nSo if I have two branches, say \"x\" and \"y\", and I want to merge them, but \nreally throw away the tree of \"x\", I would check out 'y', naturally. Then \n'git merge -s ours x'.\n\nIf the result should become the state of 'x', too, I would then just \n'git push origin y:x'.\n\nMaybe I am \"Git-braindead\" by now, so that you can make fun of me like I \nused to make fun of CVSers and SVNers...\n\nCiao,\nDscho\n"},{"id":"85366","messageId":"bd6139dc0807281709u43218e97p8ba239f3e520e10@mail.gmail.com","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807290123300.2725@eeepc-johanness","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-29T00:09:18Z","receivedAt":"2008-07-29T00:09:18Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, Jul 29, 2008 at 01:27, Johannes Schindelin\n wrote:\n> To me, this suggests that they were too married to 'production' being the\n> \"dominant\" branch.\n\n\n\n> If the result should become the state of 'x', too, I would then just\n> 'git push origin y:x'.\n\nBut this means that everybody doing a 'git pull' on that repo will get\ncomplaints when pulling, right? Should they just send out a message to\nall their users that they'll need to rebase all their changes now?\n(Not being sarcastic, am trying to work out what the recommended\nworkflow is here.)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85371","messageId":"7vsktto78y.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"20080728192651.GA26677@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T00:37:33Z","receivedAt":"2008-07-29T00:37:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> My situation was two long-running branches, \"stable\" and \"devel\",\n> both of which were worked on by many developers. One person was in\n> charge of integration and branch management. They wanted \"stable\" to\n> get the contents of \"devel\" (which were now ready for release), ignoring\n> any small fixes that had been done on \"stable\" (since they had all been\n> moved over to \"devel\" previously, but in subtly different ways that\n> would create conflicts). And \"git reset\" was not an option, because they\n> wanted to keep the history of \"stable\" in case those fixes needed to be\n> looked at later.\n\nI sense a slightly broken workflow here, whether the \"-s theirs\" strategy\nis used or the merge is done in the other direction using \"-s ours\"\nstrategy.\n\nRemember, when you create a merge commit between one history and another,\nyou are making this statement:\n\n I have looked at the tree state and the development history behind\n both of these commits, and came up with this tree, which I believe\n suits the purpose of _my_ history better than either of them.\n\nThat is why, after making such a merge with \"git merge other\", you won't\nsee any output from \"git log ..other\", which asks \"what do I have yet to\nmerge?\" Everything that was included in other is now in your history and\nthere is nothing you have to worry about having left out anymore.\n\nSo if you suspect that the sutuation \"in case those fixes needed to be\nlooked at later\" ever arises, such a merge should *not* be recorded as a\nproper merge on the 'stable' branch, because at that point when you are\ndoing that \"-s theirs\" merge (and this applies equally to the case where\nyou make \"-s ours\" merge as well), you actually have not looked at \"those\nfixes\" closely enough to make the above statement with confidence.\n\nHaving said that, that \"looking back in history\" can easily be done if you\nmark such a \"Use '-s theirs' for expediency\" merge as potentially an iffy\none in its commit log message somewhere. Later if you actually hit\nissues, you can locate such a merge commit, and inspect the output from\n\"git log $commit^2..$commit^1\". You would see those fixes the \"devel\"\nhistory did not have in the \"stable\" branch when such a merge was made.\n\nSo the above is not a fundamental objection to the approach, and that is\nwhy I said \"slightly broken\". With a proper explanation between the right\nuse case (I think what you outlined is an example of good practice) and\nthe wrong use case (for example, the one described in $gmane/89024, the\nwhole thing after 'I think \"-s theirs\" is even worse.', not just the part\nthat was quoted in $gmane/89178), I think it is Ok to have \"-s theirs\"\nstrategy in our toolset.\n\nEven though having said all of the above, I would actually prefer such a\n\"pull all of the devel down to stable\" be done with this workflow instead:\n\n (1) go to 'devel';\n (2) merge all of 'stable';\n (3) look at the result and prove it is perfect;\n (4) go to 'stable';\n (5) merge 'devel'.\n\nThe last step would be a fast-forward, and you do not need \"-s theirs\"\nanywhere in this procedure. Step (2) can be helped with \"-s ours\" (which\nhave the same issue I discussed above), but the result is checked before\nit hits the 'stable' (presumably more precious branch), which is\nconceptually a big difference. This is where the existing asymmetry\nbetween theirs and ours comes from.\n\nIncidentally, this is how 'maint' skips to tip of 'master' after a new\nmajor version is released, but 'maint' is merged up into 'master' often\nenough that we rarely need to even use \"ours\" strategy.\n"},{"id":"85394","messageId":"20080729043117.GB26997@sigill.intra.peff.net","threadId":"14719","inReplyTo":"bd6139dc0807281709u43218e97p8ba239f3e520e10@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T04:31:17Z","receivedAt":"2008-07-29T04:31:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 29, 2008 at 02:09:18AM +0200, Sverre Rabbelier wrote:\n\n> > If the result should become the state of 'x', too, I would then just\n> > 'git push origin y:x'.\n> \n> But this means that everybody doing a 'git pull' on that repo will get\n> complaints when pulling, right? Should they just send out a message to\n> all their users that they'll need to rebase all their changes now?\n> (Not being sarcastic, am trying to work out what the recommended\n> workflow is here.)\n\nI think you are missing the fact that he is doing this push _after_\nhaving merged the history into master via \"-s ours\". So it is a\nfast-forward to push at that point.\n\n-Peff\n"},{"id":"85395","messageId":"20080729043839.GC26997@sigill.intra.peff.net","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807290123300.2725@eeepc-johanness","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T04:38:39Z","receivedAt":"2008-07-29T04:38:39Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:\n\n> > So the logical sequence was:\n> > \n> > git checkout production\n> > git merge -s theirs master\n> \n> To me, this suggests that they were too married to 'production' being the \n> \"dominant\" branch.\n\nPerhaps. But I see this as an operation on the production branch: \"pull\nin master's changes, forgetting ours\". In your workflow (git checkout\nmaster && git merge -s ours production && git push origin\nmaster:production) we perform an operation on master, which doesn't seem\nas intuitive to me.\n\nNot to mention that we might not _control_ master. What about (and I\nthink Sverre mentioned something like this previously):\n\n I forked the kernel and made some changes. Some of my changes got\n applied upstream. The others are now obsolete. Now I want to bring\n myself in sync with Linus, but I want to keep my history (either\n because the history is interesting to me, or because others are basing\n their work on it).\n\nThen your workflow, while still possible within the local repository,\nmeans you are munging the \"linus\" branch, which seems wrong. That branch\nis probably even just a tracking branch, which you would not want to\nbuild on, anyway.\n\n-Peff\n"},{"id":"85398","messageId":"20080729050218.GD26997@sigill.intra.peff.net","threadId":"14719","inReplyTo":"7vsktto78y.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T05:02:18Z","receivedAt":"2008-07-29T05:02:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote:\n\n> I sense a slightly broken workflow here, whether the \"-s theirs\" strategy\n> is used or the merge is done in the other direction using \"-s ours\"\n> strategy.\n> \n> Remember, when you create a merge commit between one history and another,\n> you are making this statement:\n> \n> I have looked at the tree state and the development history behind\n> both of these commits, and came up with this tree, which I believe\n> suits the purpose of _my_ history better than either of them.\n\nRight, that is precisely what I wanted to say. These are the histories\nof the devel and stable branches, and now they both are the contents of\nstable. In this case, \"I have looked at all of the commits in stable\nthat were _not_ in devel, and confirmed that they have moral equivalents\nin devel\".\n\n> That is why, after making such a merge with \"git merge other\", you won't\n> see any output from \"git log ..other\", which asks \"what do I have yet to\n> merge?\" Everything that was included in other is now in your history and\n> there is nothing you have to worry about having left out anymore.\n\nRight, that is just what I wanted.\n\n> So if you suspect that the sutuation \"in case those fixes needed to be\n> looked at later\" ever arises, such a merge should *not* be recorded as a\n> proper merge on the 'stable' branch, because at that point when you are\n> doing that \"-s theirs\" merge (and this applies equally to the case where\n> you make \"-s ours\" merge as well), you actually have not looked at \"those\n> fixes\" closely enough to make the above statement with confidence.\n\nNo, I had looked at them with confidence. I just didn't want history\nthrown away for two reasons:\n\n - historical interest; some of the commits had counterparts in devel\n that were done differently (because the two branches had diverged),\n but it might later be interesting to see how and why the stable\n changes were done (e.g., if a similar situation arose)\n\n - this project did not rebase, favoring the simplicity of \"git pull\"\n over clean history.\n\nBear in mind that this project was not very big. I think devel had ~20\ncommits, and stable had about ~5. So it was easy to get such confidence.\n\n> Even though having said all of the above, I would actually prefer such a\n> \"pull all of the devel down to stable\" be done with this workflow instead:\n> \n> (1) go to 'devel';\n> (2) merge all of 'stable';\n> (3) look at the result and prove it is perfect;\n> (4) go to 'stable';\n> (5) merge 'devel'.\n> \n> The last step would be a fast-forward, and you do not need \"-s theirs\"\n> anywhere in this procedure. Step (2) can be helped with \"-s ours\" (which\n> have the same issue I discussed above), but the result is checked before\n> it hits the 'stable' (presumably more precious branch), which is\n> conceptually a big difference. This is where the existing asymmetry\n> between theirs and ours comes from.\n\nOf course you can do this (and that is, in fact, exactly what I did).\nBut there is no point discussing \"what hits stable\" since neither branch\nis precious. All of this is happening in a private repo that nobody is\nlooking at. So it really is a case of thinking about it as \"devel\nsubsumes stable, and then stable becomes devel\" versus \"stable is\ndiscarded in favor of master\".\n\nI think both are equally valid ways of looking at what is happening. The\nonly differences will be:\n\n - the commit message will be reversed (\"Merge X into Y\"). And this\n really comes down to \"how would I want to see this presented in 3\n months when I look at it?\". And either is valid, depending on how you\n think of the problem (but I think in both cases, you owe it to\n future readers to write a bit of text saying _why_ such a strategy\n was OK to use).\n\n - the parents will be swapped. Using \"-s theirs\" should let you ask\n \"what changes did I make on my stable branch\" using\n \"--first-parent\". I don't know how useful that is, as I don't\n actively work on that project anymore.\n\n-Peff\n"},{"id":"85399","messageId":"20080729050845.GE26997@sigill.intra.peff.net","threadId":"14719","inReplyTo":"7vvdyppv4c.fsf@gitster.siamese.dyndns.org","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T05:08:45Z","receivedAt":"2008-07-29T05:08:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 28, 2008 at 02:16:35PM -0700, Junio C Hamano wrote:\n\n> The quoted sentence by me in that message was after I explained why \"per\n> hunk theirs\" aka \"-Xtheirs\" was not such a great idea I further went on to\n> say \"by the way, '-s theirs' is even worse and here is why\".\n\nYour reason was \"it keeps your crap in the history\". And while I\ngenerally am in favor of getting rid of crap and keeping a clean\nhistory, I think it is very much dependent on the individual project's\npreferences. IOW, that history might not contain \"crap\" but rather\nnow-obsolete changes that are of historical interest.\n\nBut I do agree that -Xtheirs is crap. ;)\n\n-Peff\n"},{"id":"85425","messageId":"7viqupkxjh.fsf@gitster.siamese.dyndns.org","threadId":"14719","inReplyTo":"20080729050845.GE26997@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T06:35:30Z","receivedAt":"2008-07-29T06:35:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Your reason was \"it keeps your crap in the history\". And while I\n> generally am in favor of getting rid of crap and keeping a clean\n> history, I think it is very much dependent on the individual project's\n> preferences. IOW, that history might not contain \"crap\" but rather\n> now-obsolete changes that are of historical interest.\n>\n> But I do agree that -Xtheirs is crap. ;)\n\nYes, that is why I did not merge 'master' with \"theirs\" merge into it to\nsubsume it. I reverted -Xtheirs from 'next' (due to \"never-rewind during\nthe cycle\" rule) and intend to rebuild 'next' without it when 1.6.0 ships.\n\nHowever, that does not keep me from holding onto its tip privately (and I\ndo, as the machinery to pass -Xoption through git-merge to backends would\nbe useful later).\n\nIOW, \"now-obsolete changes that are of historical interest\" does not\nnecessarily justify a \"subsuming\" merge using \"-s ours\" or \"-s theirs\".\n"},{"id":"85442","messageId":"e2b179460807290236k214b41f2wee25c213d7c95ae3@mail.gmail.com","threadId":"14719","inReplyTo":"20080729050218.GD26997@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2008-07-29T09:36:32Z","receivedAt":"2008-07-29T09:36:32Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2008/7/29 Jeff King :\n> On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote:\n>\n> I just didn't want history thrown away for two reasons:\n>\n> - historical interest; some of the commits had counterparts in devel\n> that were done differently (because the two branches had diverged),\n> but it might later be interesting to see how and why the stable\n> changes were done (e.g., if a similar situation arose)\n>\n> - this project did not rebase, favoring the simplicity of \"git pull\"\n> over clean history.\n>\n> Bear in mind that this project was not very big. I think devel had ~20\n> commits, and stable had about ~5. So it was easy to get such confidence.\n\nIs there any reason you couldn't have reverted the stable commits in\npreparation for the merge from devel?\n\nI.e. these commits were necessary to fix problems in production, they\nnow need to be reverted in order to cleanly apply the changes for the\nnext stable version, which includes fixes for all of these problems.\n\nI can see you'd be preserving twice as much history instead of\nthrowing any away, but if scalability became an issue, you could\nalways squash all the reverts into one pre-merge commit.\n\ngit-merge-theirs-revert anyone?\n\nMike\n"},{"id":"85446","messageId":"alpine.DEB.1.00.0807291301060.4631@eeepc-johanness","threadId":"14719","inReplyTo":"20080729043839.GC26997@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T11:05:11Z","receivedAt":"2008-07-29T11:05:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 29 Jul 2008, Jeff King wrote:\n\n> On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:\n> \n> > > So the logical sequence was:\n> > > \n> > > git checkout production\n> > > git merge -s theirs master\n> > \n> > To me, this suggests that they were too married to 'production' being \n> > the \"dominant\" branch.\n> \n> Perhaps. But I see this as an operation on the production branch: \"pull\n> in master's changes, forgetting ours\".\n\nFirst of all, I cannot say how wrong it is to forget any changes in a \nproduction branch without proper explanation. I.e. without a commit \nmessage explaining _why_ the change was wrong to begin with.\n\nIt is messy at best, and I am happy that Git does not make that easy.\n\n> In your workflow (git checkout master && git merge -s ours production && \n> git push origin master:production) we perform an operation on master, \n> which doesn't seem as intuitive to me.\n\nBut why? Isn't the _content_ of \"master\" what we want?\n\n> Not to mention that we might not _control_ master.\n\nThis is Git. We control all local branches.\n\n> What about (and I think Sverre mentioned something like this \n> previously):\n> \n> I forked the kernel and made some changes. Some of my changes got\n> applied upstream. The others are now obsolete. Now I want to bring\n> myself in sync with Linus, but I want to keep my history (either\n> because the history is interesting to me, or because others are basing\n> their work on it).\n> \n> Then your workflow, while still possible within the local repository, \n> means you are munging the \"linus\" branch, which seems wrong. That branch \n> is probably even just a tracking branch, which you would not want to \n> build on, anyway.\n\nNo, this workflow almost _dictates_ a plain \"pull\" into your local branch. \nThe fact that a few commits were applied to upstream usually only means \nthat your merge succeeds trivially, since the merged branches contain the \n_same_ changes.\n\nCiao,\nDscho\n"},{"id":"85459","messageId":"20080729123629.GA12069@sigill.intra.peff.net","threadId":"14719","inReplyTo":"alpine.DEB.1.00.0807291301060.4631@eeepc-johanness","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T12:36:30Z","receivedAt":"2008-07-29T12:36:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 29, 2008 at 01:05:11PM +0200, Johannes Schindelin wrote:\n\n> > Perhaps. But I see this as an operation on the production branch: \"pull\n> > in master's changes, forgetting ours\".\n> \n> First of all, I cannot say how wrong it is to forget any changes in a \n> production branch without proper explanation. I.e. without a commit \n> message explaining _why_ the change was wrong to begin with.\n\nOf course; I even mentioned the same in another part of the thread. But\nthat isn't a difference between \"ours\" and \"theirs\"; any time you are\ndiscarding some changes, you should mention why.\n\n> > In your workflow (git checkout master && git merge -s ours production && \n> > git push origin master:production) we perform an operation on master, \n> > which doesn't seem as intuitive to me.\n> \n> But why? Isn't the _content_ of \"master\" what we want?\n\nSure, which means we must _read_ from master. But you are _changing_\nmaster. Whereas I view this as an operation on the production branch.\n\nPlease don't misunderstand me. I am not saying your way of thinking\nabout it is wrong (or even less right than mine). What I have been\ntrying to say this whole thread is that it is reasonable for a user to\nmodel the goal as I have described, and that git can easily support the\ndirect implementation of achieving that goal (which is what Sverre asked\noriginally -- is this useful to people?).\n\n> > Not to mention that we might not _control_ master.\n> \n> This is Git. We control all local branches.\n\nSort of. Consider the kernel example I gave. A \"linus\" branch represents\n\"this is where Linus is.\" But that _isn't_ where Linus is if you have\nadded an extra merge commit to it. So either we throw away the change\nmade to the \"linus\" branch, or we forever have extra merges that Linus\ndoes not have.\n\nSo yes, obviously you can do whatever you like with your local branches.\nBut you complained in my example that the \"production\" branch was\nunnecessarily being treated as \"dominant\". My example was meant to\nindicate that the \"thrown away\" branch is dominant for a reason (in this\ncase, it is my work branch, while the other is a tracking branch).\n\n> No, this workflow almost _dictates_ a plain \"pull\" into your local branch. \n> The fact that a few commits were applied to upstream usually only means \n> that your merge succeeds trivially, since the merged branches contain the \n> _same_ changes.\n\nI don't see the point in talking about \"usually\". In the scenario in\nwhich I used it, the merge _didn't_ succeed trivially. Of course,\nusually you would not use \"-s theirs\". But the question was \"is this\never useful?\" and my answer was \"rarely, but here is an example of when\nI wanted it.\"\n\nIf you are using \"-s theirs\" frequently, you are probably doing\nsomething wrong. But that doesn't mean it is wrong for it to exist.\n\n-Peff\n"},{"id":"85461","messageId":"bd6139dc0807290542q24312e9k1f36e8c65df6c4aa@mail.gmail.com","threadId":"14719","inReplyTo":"20080729123629.GA12069@sigill.intra.peff.net","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-29T12:42:09Z","receivedAt":"2008-07-29T12:42:09Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, Jul 29, 2008 at 14:36, Jeff King wrote:\n\n\n> If you are using \"-s theirs\" frequently, you are probably doing\n> something wrong. But that doesn't mean it is wrong for it to exist.\n\nExactly, thank you for that :). I hope it is clear to everybody what I\nmeant now, although it seems that especially Junio and Dscho feel\n'git-merge-theirs' should not be part of git in the suggested form.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85462","messageId":"20080729124213.GB12069@sigill.intra.peff.net","threadId":"14719","inReplyTo":"e2b179460807290236k214b41f2wee25c213d7c95ae3@mail.gmail.com","subject":"Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-29T12:42:13Z","receivedAt":"2008-07-29T12:42:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 29, 2008 at 10:36:32AM +0100, Mike Ralphson wrote:\n\n> > I just didn't want history thrown away for two reasons:\n> >\n> > - historical interest; some of the commits had counterparts in devel\n> > that were done differently (because the two branches had diverged),\n> > but it might later be interesting to see how and why the stable\n> > changes were done (e.g., if a similar situation arose)\n> >\n> > - this project did not rebase, favoring the simplicity of \"git pull\"\n> > over clean history.\n> >\n> > Bear in mind that this project was not very big. I think devel had ~20\n> > commits, and stable had about ~5. So it was easy to get such confidence.\n> \n> Is there any reason you couldn't have reverted the stable commits in\n> preparation for the merge from devel?\n\nNo, there is no technical reason. I think that is a perfectly valid way\nof accomplishing the same goal (as is switching to the \"kept\" branch and\nusing \"-s ours\"). It's just that we had a particular mental model, and\nthe simplest way of translating that model into a git history graph was\nas I described.\n\nAgain, I don't think this is a common problem, and I have certainly not\nbeen aching for \"-s theirs\". The question was whether such a thing might\nbe useful, and I think it is, if only because it most directly matches\nhow a user might be thinking of the problem; for other users, or other\nsimilar situations, one of the other methods might make more sense.\n\nTo me, seeing a commit that joins two histories with a comment saying\n\"these two branches are now becoming the same, but we don't care about\nwhat happened down this ancestry chain because of X\" most directly\nmodels what happened (in my case).\n\n-Peff\n"}]}