On Fri, Apr 15, 2011 at 7:21 PM, Marius Storm-Olsen <mstormo@xxxxxxxxx> wrote: > Hi, > > I'm trying to rebase a rather large series of patches, which also contains a > couple of merges which I'd like to recreate in the rebase, and for the other > conflicts I'd like git to automatically choose 'ours'. > > So, I run > git rebase -p -X ours -X patience -X ignore-all-space --onto foo bar baz > and I get > error: unknown switch `X' Interactive rebase uses cherry-pick internally. Jonathan added support for -X to that command not too long ago (in commit 67ac1e1, late last year), so it should be pretty straight-forward to add support for what you want. Maybe I'll do that in a few weeks when I get back from vacation. A related topic is _when_ to use the strategy (and strategy options). I asked the question on http://thread.gmane.org/gmane.comp.version-control.git/164241/focus=164543, but I will try to clarify here. I saw that when rebase -p was initially introduced by Johannes in f09c9b8 in 2007, he gave this example: Example: X \ A---M---B / ---o---O---P---Q When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield X \ ---o---O---P---Q---A'---M'---B' Is that similar to what you want? I have normally been thinking about an example that looks more like: C---D / \ A---B---M / ---o---O---P---Q which would yield C'---D' / \ ---o---O---P---Q---A'---B'---M' In such a case, it probably makes sense to use the same strategy to create A' through D', because the upstream change for all of them would be the changes from O to Q (the merge base is O). However, when applying M to form M', that part of the history is not involved (the merge base is A'). Would it be completely insane to stop passing the strategy when recreating merges? It seems to me that it would at least be better in the second example above. Johannes, do you think that would break things in the first example? A more advanced solution would be recreate the merge using rerere. We could first redo the merge from D to B and reset the tree to look like in M, then record the resolutions and reuse them when doing the merge to form M'. Makes sense? Overkill? If we want to avoid interfering with the normal rerere cache, I guess we could use a separate rerere cache (which I don't think is currently supported). > Is there any work around to allow me to achieve the same result? Not that I know of. (Except, of course, piece-wise rebasing the linear parts of history and doing the merges manually.) /Martin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html