git rebase -p doesn't understand -X

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'

Clearly this is because when you use the -p option, everything goes through the --interactive engine, instead of the normal procedure. I would still like to maintain that this is a bug, and that even though -p uses a different engine, to be able to recreate the merges, it should still be able to let me tune the overall merge strategy.

Is there any work around to allow me to achieve the same result?

Thanks!

On Fri, Apr 15, 2011 at 7:21 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:

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).

Not that I know of. (Except, of course, piece-wise rebasing the linear parts of history and doing the merges manually.)

/Martin

Hi Martin,

Martin von Zweigbergk wrote:

That would be excellent.

I agree with your analysis.  In particular:

I have a vague feeling that honoring --strategy and --strategy-option would be confusing here. The merge used in cherry-picking A does not have much to do with the merge used to reincorporate changes from X.

Well, that is my intuition, but most of the examples I can think of lead to the opposite conclusion! If I use -Xrenormalize, because P changed the line-ending style, then I will want the same option when merging X on top. Similarly, if I use -Xsubtree=src, because Q moved all existing files in the source tree under src/, then with luck the same trick will work when replaying the merge of X.

Luckily there is an exception to prove the intuition ok.  If X was the
first parent of M and I am using -Xours to sloppily favor upstream's
decisions when rebasing my history on top of it, using -Xours to favor
choices from X (which is my own) would be just plain wrong.  (Phew.)
 

Likewise in this case.

[...]

Here's a vague and probably wrong idea about another way to re-create merges.

When cherry-picking a patch (A, say), we run a three-way merge, with A^ as merge base, A as "their" change, and the new parent for A (= Q) as "our" change.

Maybe the same trick could work for re-creating merges. In your first example, run a three-way merge with M^ (= A) as merge base, M as "their" change, and the new parent for M (= A') as "our" change. That only works in such a straightforward way if only one of M's parents was rewritten, though. More generally it could be possible to run a sequence of three-way merges:

	base=M^1, theirs=M, ours=(M^1)' => call the result "m_1"
	base=M^2, theirs=m_1, ours=(M^2)' => call the result "m_2"
	...

At this point it gets ugly enough that just redoing the merge might be simpler.

The main problem with rerere is that it can make mistakes. In the long run, I wonder if rebase could learn to take into account something more explicit like Junio's merge-fix mechanism (see origin/todo:Reintegrate).

Thanks; that was interesting. Jonathan