Re: git rebase -p doesn't understand -X

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

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