{"thread":{"id":"27106","subject":"git rebase -p doesn't understand -X","startedAt":"2011-04-15T17:21:24Z","lastAt":"2011-04-20T23:40:04Z","messageCount":3,"participants":["Marius Storm-Olsen","Martin von Zweigbergk","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"165911","messageId":"4DA87E94.2050700@gmail.com","threadId":"27106","inReplyTo":null,"subject":"git rebase -p doesn't understand -X","fromName":"Marius Storm-Olsen","fromEmail":"mstormo@gmail.com","sentAt":"2011-04-15T17:21:24Z","receivedAt":"2011-04-15T17:21:24Z","isPatch":false,"sender":{"key":"mstormo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1500?v=4"},"body":"Hi,\n\nI'm trying to rebase a rather large series of patches, which also \ncontains a couple of merges which I'd like to recreate in the rebase, \nand for the other conflicts I'd like git to automatically choose 'ours'.\n\nSo, I run\n     git rebase -p -X ours -X patience -X ignore-all-space --onto foo \nbar baz\nand I get\n     error: unknown switch `X'\n\nClearly this is because when you use the -p option, everything goes \nthrough the --interactive engine, instead of the normal procedure. I \nwould still like to maintain that this is a bug, and that even though -p \nuses a different engine, to be able to recreate the merges, it should \nstill be able to let me tune the overall merge strategy.\n\nIs there any work around to allow me to achieve the same result?\n\nThanks!\n\n-- \n.marius\n"},{"id":"166069","messageId":"BANLkTi=sW_J4LGS=XRuLrwYZTgx4GP65PA@mail.gmail.com","threadId":"27106","inReplyTo":"4DA87E94.2050700@gmail.com","subject":"Re: git rebase -p doesn't understand -X","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-04-19T09:06:38Z","receivedAt":"2011-04-19T09:06:38Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Fri, Apr 15, 2011 at 7:21 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:\n> Hi,\n>\n> I'm trying to rebase a rather large series of patches, which also contains a\n> couple of merges which I'd like to recreate in the rebase, and for the other\n> conflicts I'd like git to automatically choose 'ours'.\n>\n> So, I run\n>    git rebase -p -X ours -X patience -X ignore-all-space --onto foo bar baz\n> and I get\n>    error: unknown switch `X'\n\nInteractive rebase uses cherry-pick internally. Jonathan added support\nfor -X to that command not too long ago (in commit 67ac1e1, late last\nyear), so it should be pretty straight-forward to add support for what\nyou want. Maybe I'll do that in a few weeks when I get back from\nvacation.\n\nA related topic is _when_ to use the strategy (and strategy options).\nI asked the question on\nhttp://thread.gmane.org/gmane.comp.version-control.git/164241/focus=164543,\nbut I will try to clarify here.\n\nI saw that when rebase -p was initially introduced by Johannes in\nf09c9b8 in 2007, he gave this example:\n\n\n    Example:\n\n               X\n                \\\n             A---M---B\n            /\n    ---o---O---P---Q\n\n    When the current HEAD is \"B\", \"git rebase -i -p --onto Q O\" will yield\n\n                   X\n                     \\\n    ---o---O---P---Q---A'---M'---B'\n\n\nIs that similar to what you want? I have normally been thinking about\nan example that looks more like:\n\n               C---D\n              /     \\\n             A---B---M\n            /\n    ---o---O---P---Q\n\nwhich would yield\n\n                         C'---D'\n                        /       \\\n    ---o---O---P---Q---A'---B'---M'\n\n\nIn such a case, it probably makes sense to use the same strategy to\ncreate A' through D', because the upstream change for all of them\nwould be the changes from O to Q (the merge base is O). However, when\napplying M to form M', that part of the history is not involved (the\nmerge base is A').\n\nWould it be completely insane to stop passing the strategy when\nrecreating merges? It seems to me that it would at least be better in\nthe second example above. Johannes, do you think that would break\nthings in the first example?\n\nA more advanced solution would be recreate the merge using rerere. We\ncould first redo the merge from D to B and reset the tree to look like\nin M, then record the resolutions and reuse them when doing the merge\nto form M'. Makes sense? Overkill? If we want to avoid interfering\nwith the normal rerere cache, I guess we could use a separate rerere\ncache (which I don't think is currently supported).\n\n> Is there any work around to allow me to achieve the same result?\n\nNot that I know of. (Except, of course, piece-wise rebasing the linear\nparts of history and doing the merges manually.)\n\n\n/Martin\n"},{"id":"166167","messageId":"20110420233949.GA10305@elie","threadId":"27106","inReplyTo":"BANLkTi=sW_J4LGS=XRuLrwYZTgx4GP65PA@mail.gmail.com","subject":"Re: git rebase -p doesn't understand -X","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-20T23:40:04Z","receivedAt":"2011-04-20T23:40:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Martin,\n\nMartin von Zweigbergk wrote:\n\n> Interactive rebase uses cherry-pick internally. Jonathan added support\n> for -X to that command not too long ago (in commit 67ac1e1, late last\n> year), so it should be pretty straight-forward to add support for what\n> you want. Maybe I'll do that in a few weeks when I get back from\n> vacation.\n\nThat would be excellent.\n\n> A related topic is _when_ to use the strategy (and strategy options).\n\nI agree with your analysis.  In particular:\n\n>     Example:\n>\n>                X\n>                 \\\n>              A---M---B\n>             /\n>     ---o---O---P---Q\n>\n>     When the current HEAD is \"B\", \"git rebase -i -p --onto Q O\" will yield\n>\n>                           X\n>                            \\\n>     ---o---O---P---Q---A'---M'---B'\n\nI have a vague feeling that honoring --strategy and --strategy-option\nwould be confusing here.  The merge used in cherry-picking A does not\nhave much to do with the merge used to reincorporate changes from X.\n\nWell, that is my intuition, but most of the examples I can think of\nlead to the opposite conclusion!  If I use -Xrenormalize, because P\nchanged the line-ending style, then I will want the same option when\nmerging X on top.  Similarly, if I use -Xsubtree=src, because Q moved\nall existing files in the source tree under src/, then with luck the\nsame trick will work when replaying the merge of X.\n\nLuckily there is an exception to prove the intuition ok.  If X was the\nfirst parent of M and I am using -Xours to sloppily favor upstream's\ndecisions when rebasing my history on top of it, using -Xours to favor\nchoices from X (which is my own) would be just plain wrong.  (Phew.)\n \n>                C---D\n>               /     \\\n>              A---B---M\n>             /\n>     ---o---O---P---Q\n>\n> which would yield\n>\n>                           C'---D'\n>                          /      \\\n>     ---o---O---P---Q---A'---B'---M'\n\nLikewise in this case.\n\n> A more advanced solution would be recreate the merge using rerere.\n[...]\n\nHere's a vague and probably wrong idea about another way to re-create\nmerges.\n\nWhen cherry-picking a patch (A, say), we run a three-way merge, with\nA^ as merge base, A as \"their\" change, and the new parent for A (= Q)\nas \"our\" change.\n\nMaybe the same trick could work for re-creating merges.  In your first\nexample, run a three-way merge with M^ (= A) as merge base, M as\n\"their\" change, and the new parent for M (= A') as \"our\" change.  That\nonly works in such a straightforward way if only one of M's parents\nwas rewritten, though.  More generally it could be possible to run a\nsequence of three-way merges:\n\n\tbase=M^1, theirs=M, ours=(M^1)' => call the result \"m_1\"\n\tbase=M^2, theirs=m_1, ours=(M^2)' => call the result \"m_2\"\n\t...\n\nAt this point it gets ugly enough that just redoing the merge might be\nsimpler.\n\nThe main problem with rerere is that it can make mistakes.  In the\nlong run, I wonder if rebase could learn to take into account\nsomething more explicit like Junio's merge-fix mechanism (see\norigin/todo:Reintegrate).\n\nThanks; that was interesting.\nJonathan\n"}]}