{"thread":{"id":"22958","subject":"merge -s ours question","startedAt":"2010-03-08T22:26:20Z","lastAt":"2010-03-08T23:33:17Z","messageCount":3,"participants":["Jay Soffian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136417","messageId":"76718491003081426j4329e322we91fc6fe13f2d03@mail.gmail.com","threadId":"22958","inReplyTo":null,"subject":"merge -s ours question","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-03-08T22:26:20Z","receivedAt":"2010-03-08T22:26:20Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Here's the scenario,\n\nI have a muddled development branch that has a mix of local development and\nupstream merges:\n\n upstream 1--2--3--4--5\n           \\     \\     \\\n      dev   o--A--x--B--x ... Y\n\nIt took a lot of work, but I backported everything newer than A using rebase\nand cherry-pick, and omitting the merges, giving me a dev' clean of merges\nfrom upstream:\n\n     dev'   o--A'--B' ... Y'\n           /\n upstream 1--2--3--4--5\n           \\     \\     \\\n      dev   o--A--x--B--x ... Y\n\nNow it turns out that going forward, I need two development branches, one\nthat's based on a newer version of upstream for which the merge work was\nalready done in the original dev. In an ideal world I'd have this history:\n\nupstream 1--2--3--4--5\n          \\           \\\n    dev2   \\           o--o--o--o\n            \\\n    dev1     o--o--o--o--o\n\nAnd I would periodically merge dev1 into dev2 (dev2 requires the work being\ndone on dev1). The problem is that my backported dev' has a mix of dev1 and\ndev2 and it's impossible for me to tease them apart at this point. So my plan\nwas to do this:\n\n\n     dev'   o--A'--B' ... Y'\n           /               \\\n upstream 1--2--3--4--5     \\\n           \\     \\     \\     \\\n      dev   o--A--x--B--x ... Z\n\nWhere Z is created using using \"git merge -s ours dev'\". Is it correct that\nthis should do nothing more than give me a new merge base for dev and dev'?\nThen going forward I can merge from dev' to dev per usual.\n\nThanks,\n\nj.\n"},{"id":"136433","messageId":"7vhboql8uu.fsf@alter.siamese.dyndns.org","threadId":"22958","inReplyTo":"76718491003081426j4329e322we91fc6fe13f2d03@mail.gmail.com","subject":"Re: merge -s ours question","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-08T22:57:45Z","receivedAt":"2010-03-08T22:57:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> It took a lot of work, but I backported everything newer than A using rebase\n> and cherry-pick, and omitting the merges, giving me a dev' clean of merges\n> from upstream:\n>\n>      dev'   o--A'--B' ... Y'\n>            /\n>  upstream 1--2--3--4--5\n>            \\     \\     \\\n>       dev   o--A--x--B--x ... Y\n\nI understand that at this point \"dev'\" is the moral equivalent of what you\ncalled \"dev1\" in the next picture.\n\n> upstream 1--2--3--4--5\n>           \\           \\\n>     dev2   \\           o--o--o--o\n>             \\\n>     dev1     o--o--o--o--o\n\nIt is unclear what commits on dev2 branch are about in this picture.  Are\nthey replay of what you have on dev1?  Or are they about a feature that is\ndifferent from what dev1 does, perhaps using what dev1 have already done,\nor perhaps totally independent of dev1?\n\nIf \"dev1\" and \"dev'\" are the moral equivalents, and dev2 wants to use what\ndev1 did _and_ what is in updated upstream (i.e. dev2 cannot build without\neither dev1 nor some of the feature/fix in \"2\"...\"5\"), then I would\nprobably build a history that looks like this:\n\n                      o--o--o dev2 (builds on top of dev1)\n                     /\n                 .--*   merge between dev1 and upstream\n                /  /\n      o--o--o--o  /   dev1\n     /           /\n    1--2--3--4--5     upstream\n  \nand give a pull request to the upstream for \"*\" to incorporate the fully\ncooked work done on dev1.\n\nAlso if \"dev'\" and \"dev1\" are the moral equivalents, then the merge \"*\"\nabove _should_ match exactly what you had at \"Y\" in \"dev\" in the original\nmergy history.  So after creating \"*\", you may want to do a regular merge\n(IOW, I don't think \"-s ours\" is necessary if you rebuilt \"dev1\" right)\nbetween it and 'dev' to create \"M\" that should result in the same tree:\n\n                 .--*   merge between dev1 and upstream\n                /  / \\\n      o--o--o--o  /   \\        dev1\n     /           /     \\\n    1--2--3--4--5       \\      upstream\n     \\     \\     \\       \\\n      o--A--x--B--x-..-Y--M    dev\n                           \\\n                            o--o--o dev2'\n\nand build \"dev2'\" on \"dev\" instead; but you probably cannot offer \"dev\" to\nbe pulled to the upstream due to the criss-cross mess (that was the whole\nreason you did \"dev1\" in the first place), and doing so would make \"dev2'\"\nunpullable for the same reason.  So I don't see much point in doing that\nmerge \"M\" nor keeping \"dev\" branch around, once you verified that \"*\" and\n\"Y\" matches to make sure your rebuilt dev1 has what dev has, and it is\nwhat dev should have looked like in the first place.\n\nIf you want to keep merging from dev1 to dev2 because dev1 is still not\nready, you might want to choose to rebase dev2 on top of dev1 instead.\n"},{"id":"136439","messageId":"76718491003081533r441506e9n48afee2021e7bad4@mail.gmail.com","threadId":"22958","inReplyTo":"7vhboql8uu.fsf@alter.siamese.dyndns.org","subject":"Re: merge -s ours question","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-03-08T23:33:17Z","receivedAt":"2010-03-08T23:33:17Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Mar 8, 2010 at 5:57 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jay Soffian <jaysoffian@gmail.com> writes:\n>\n>> It took a lot of work, but I backported everything newer than A using rebase\n>> and cherry-pick, and omitting the merges, giving me a dev' clean of merges\n>> from upstream:\n>>\n>>      dev'   o--A'--B' ... Y'\n>>            /\n>>  upstream 1--2--3--4--5\n>>            \\     \\     \\\n>>       dev   o--A--x--B--x ... Y\n>\n> I understand that at this point \"dev'\" is the moral equivalent of what you\n> called \"dev1\" in the next picture.\n>\n>> upstream 1--2--3--4--5\n>>           \\           \\\n>>     dev2   \\           o--o--o--o\n>>             \\\n>>     dev1     o--o--o--o--o\n>\n> It is unclear what commits on dev2 branch are about in this picture.  Are\n> they replay of what you have on dev1?  Or are they about a feature that is\n> different from what dev1 does, perhaps using what dev1 have already done,\n> or perhaps totally independent of dev1?\n>\n> If \"dev1\" and \"dev'\" are the moral equivalents, and dev2 wants to use what\n> dev1 did _and_ what is in updated upstream (i.e. dev2 cannot build without\n> either dev1 nor some of the feature/fix in \"2\"...\"5\"),\n\nSorry I was unclear in my diagrams, and you guessed correctly, dev2\nneeds both dev1 and newer commits from upstream. So a correct \"ideal\"\npicture would've been:\n\nupstream 1--2--3--4--5.\n          \\            \\\n    dev2   \\            o--o--o--o\n            \\          /\n    dev1     o--o--o--o--o\n\n\nNow, development will continue on all three branches, with dev2\nneeding changes from both dev1 and upstream. In fact, dev1 may also\nperiodically need changes from upstream, but for the foreseeable\nfuture, dev1 will be based on an older version of upstream than dev2.\n\n> then I would\n> probably build a history that looks like this:\n>\n>                      o--o--o dev2 (builds on top of dev1)\n>                     /\n>                 .--*   merge between dev1 and upstream\n>                /  /\n>      o--o--o--o  /   dev1\n>     /           /\n>    1--2--3--4--5     upstream\n>\n> and give a pull request to the upstream for \"*\" to incorporate the fully\n> cooked work done on dev1.\n\nOkay. One detail I left out is that dev1 and dev2 will never go\nupstream. They are forever downstream. Hopefully at some point dev1\nand dev2 can be based on the same upstream commit, but for now dev2\nwill periodically be merging from dev1 and will remain on a newer\nupstream commit than dev1. (Periodically, both dev1 and dev2 may merge\nfrom upstream, but it will be the case that dev1 merges from an older\nupstream commit than dev2.)\n\n> Also if \"dev'\" and \"dev1\" are the moral equivalents, then the merge \"*\"\n> above _should_ match exactly what you had at \"Y\" in \"dev\" in the original\n> mergy history.  So after creating \"*\", you may want to do a regular merge\n> (IOW, I don't think \"-s ours\" is necessary if you rebuilt \"dev1\" right)\n> between it and 'dev' to create \"M\" that should result in the same tree:\n>\n>                 .--*   merge between dev1 and upstream\n>                /  / \\\n>      o--o--o--o  /   \\        dev1\n>     /           /     \\\n>    1--2--3--4--5       \\      upstream\n>     \\     \\     \\       \\\n>      o--A--x--B--x-..-Y--M    dev\n>                           \\\n>                            o--o--o dev2'\n>\n> and build \"dev2'\" on \"dev\" instead; but you probably cannot offer \"dev\" to\n> be pulled to the upstream due to the criss-cross mess (that was the whole\n> reason you did \"dev1\" in the first place), and doing so would make \"dev2'\"\n> unpullable for the same reason.  So I don't see much point in doing that\n> merge \"M\" nor keeping \"dev\" branch around, once you verified that \"*\" and\n> \"Y\" matches to make sure your rebuilt dev1 has what dev has, and it is\n> what dev should have looked like in the first place.\n>\n> If you want to keep merging from dev1 to dev2 because dev1 is still not\n> ready, you might want to choose to rebase dev2 on top of dev1 instead.\n\nOkay. I think I have more work ahead of me creating '*'. I was trying\nto avoid having to do that. It is actually composed of multiple merges\nwith some fairly complex resolutions, but maybe rerere-train and\nrerere can help me here.\n\nj.\n"}]}